[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision)

From: Kazunobu Kuriyama
Subject: Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision)
Date: Fri, 23 Jan 2004 02:43:47 +0900
User-agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1

Richard Frith-Macdonald wrote:


Just to clarify my position ...

I definitely want the archiver format (ie what the archiver reads/writes, rather than
what the encoding/decoding code in each class being archived does) to be
MacOS-X compatible ... so people can implement their own classes in such a way that they can have portable archives. I'm doing this.

I'll look into this again.

I would like implementations of keyed archiving code for library classes to be
reverse engineered from Apple archives ... so that people can use library
classes when archiving their own objects, and still have portable archives.

I think nobody is against this idea...

However, I'm not planning to do all that work on my own (though I might
implement some keyed archiving coding for base classes) ... as I feel that
people who want this should really be prepared to contribute the code for
the classes they use themselves.

Yes, we can expect it. I'm not sure, however, whether or not the contributors also take responsibility for maintaining their contributed code and we can take it for granted. Because there are a lot of -initWithCoder:/-encodeWithCoder: in the libraries,
I don't think we should overlook it.

I *don't* believe we should implement keyed archiving code for individual
classes which is not compatible with MacOS-X code for the same classes.

I'm afraid this scatters much code which is almost impossible to maintain as
a whole. The total number of the modified code would amount to 9,000 to 10,000 because the code will expectedly doubles (or more) when we add keyed archiving
support to it. To address this problem, how about the following scheme?

(1) We implement each of iniWithCoder:/encodeWithCoder based *only* on GNUstep's internal structure. This makes implementation and maintenance faily easier
   because we don't need to care for Apple's at this level.
(2) All needed conversions from GNUstep to Apple and vice versa are done within
   archiveRootObject, unarchiveObject*, and their friends.  In other words,
all differences between GNUstep and Apple is absorbed/encapsulated in these methods (or yet another class for this purpose may be possible). This looks making the implementation feasible because we could know interrelation of objects, or an object graph, from a resulting NSCoder, and thus the conversions being made easier (if possible). We could convert the NSCoder into a new one
   and use the latter for compatibility purpose.  Also, we could change the
   behavior through the system defaults, as you noted somewhere else.

I'm not sure this is really feasible, though. Just wanted to address the problem.

We have had a keyed coding API in GNUstep pretty much forever ... but
nobody uses it as far as I know, so there is obviously not enough intrinsic
value in keyed archiving that we should ignore the potential for MacOS-X
compatibility when writing coders for classes.

I feel we definitely need to distinguish archiving from serialization in this particular context because the former must take interrelation between objects
into consideration but the latter not.


I see archive compatibility for the library classes rather like api compatibility ... it's a good thing, and we should aim for it, but we know it's a moving target
and can never be perfect.  We can each decide how much time we want to
devote to it.

Before jumping into this conclusion, shall we give another chance to our
brains so that we can enjoy admirable laziness?  I hope we can make it.

It has the nice  characteristic that any work on it is highly isolated
from the rest of the code and can therefore be done with negligible
impact on people who aren't interested in it.


- Kazunobu Kuriyama

reply via email to

[Prev in Thread] Current Thread [Next in Thread]