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

[Richard Frith-Macdonald]

On 21 Jan 2004, at 03:54, Gregory John Casamento wrote:

> Richard,
>
> --- Richard Frith-Macdonald <richard@brainstorm.co.uk> wrote:
> > On 20 Jan 2004, at 02:28, Alexander Malmberg wrote:
> >
> > > Richard Frith-Macdonald wrote:
> > > > Yep ... especially time consuming as we want to reverse engineer the
> > > > encoding of the apple classes .. which, as the internal structures 
> > > > of
> > > > our classes differ from Apples,  might mean we are archiving 
> > > > different
> > > > information to what the current methods do, and reconstructing the
> > > > information we need from that.
> > >
> > > Just to clarify: this seems to imply that you think that GNUstep's
> > > encoders/decoders should be _directly_ compatible with apple 
> > > archives,
> > > which seems like a Very Bad Idea (as opposed to writing a standalone
> > > translator, which is a separate project). Is this really what you
> > > meant?
> >
> > Yes.  There are people who want MacOS-X compatibility ... and I don't
> > think they should be willfully denied that option.
>
> No one is saying that they should be denied this option.   But that's 
> exactly
> what it should be, an option.
>
> I am very much for crossplatform compatibility, but I believe that we 
> should
> archive our classes in a natural way and should not compute/derive 
> values which
> should be used during archiving or unarchiving in our classes based on 
> what
> Apple has stored in thier archives.   In some cases what we archive 
> and what
> they archive for a given class are very different.
>
> This is not to mention the fact that (and this goes *entirely* without 
> saying,
> but I will anyways) files saved from Gorm which are .nib files will be 
> expected
> to be readable on every version of Mac OS X.   Thankfully, I've got 
> 10.2 and
> I'm about to get 10.3, but it won't be easy to maintain compatibility 
> in the
> future.


If I wrote anything which could be construed as implying that I believe 
in
forcing anyone to change existing archive formats to match MacOS-X,
I'm sorry.  That certainly wasn't intended.

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.

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.

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, while new keyed archive code would generally
be written to be MacOS-X compatible.

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.

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.