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

[Kazunobu Kuriyama]

Richard Frith-Macdonald wrote:

<snip>

> The NSCoder API is extended so that  encodeWithCoder: and initWithCoder:
> methods can  determine whether they are being encoded with a keyed
> archiver or an old style archiver ... so they can behave differently 
> for each. 

Yes.

> The GNUstep base library provides runtime macosx compatibility setting
> via the user defaults system ... so encodeWithCoder: and initWithCoder:
> methods are also able to behave differently  on the basis of these 
> settings. 

Yes.

> It seemed obvious to me that when adding keyed archiver support to
> coding/decoding methods, the existing code would be retained for
> non-keyed archives,

I think this is right.

> while new keyed archive code would generally
> be written to be MacOS-X compatible. 

This is the point I'd like to make sure of.  Does "be MacOS-X 
compatible" mean that
archives resulting from the new GNUstep's keyed archiver could be used 
with both
GNUstep and MacOS-X, or, its format (e.g., the names of keys) would be 
merely the
same as that of MacOS-X?

If it means the latter, the work for modifying 
initWithCoder:/encodeWithCoder:
is expected to be tedious but straightforward. 

For the former, however, these methods must inherently know the mapping from
a GNUstep's object graph to the corresponding MacOS-X's one and vice versa,
which I think is the point you suggested when you replied to my note on
the statistics.  Dealing with the mappings leads to the problems Gregory
pointed out.

Though I rather prefer the former compatibility if possible, I'm not 
sure how
the difficulty is overcome.  That's why I made a bitter compromise from the
beginning.  Too soon to give it up?

> If there is a pressing need for keyed archive support to be added to
> a class in a non-macosx-compatible manner, the incompatible version
> could be controlled by the user defaults system.   My guess is that
> this would rarely be necessary ... but that is just a guess, I don't 
> think
> we will really know until we try writing new coding/decoding stuff. 

I don't think anybody likes an avoidable non-compatiblity.  IMHO, the 
problem
is rather a matter of feasibility and maintenability.

> So as far as I can see, adding keyed archiving gives us the opportunity
> to move towards portable/compatible archives without breaking any
> existing stuff.

Indeed, it's a good opportunity.

- Kazunobu Kuriyama