[Top][All Lists]

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

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

From: Richard Frith-Macdonald
Subject: Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision)
Date: Wed, 21 Jan 2004 17:34:52 +0000

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


--- Richard Frith-Macdonald <address@hidden> 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

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

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.

reply via email to

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