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

[Kazunobu Kuriyama]

Richard Frith-Macdonald wrote:

<snip>

> 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.

<snip>

> 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. 

Absolutely.

- Kazunobu Kuriyama