[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,
--- 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.
- NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), (continued)
- NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Kazunobu Kuriyama, 2004/01/19
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Richard Frith-Macdonald, 2004/01/19
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Gregory John Casamento, 2004/01/19
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Richard Frith-Macdonald, 2004/01/20
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Kazunobu Kuriyama, 2004/01/21
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Alexander Malmberg, 2004/01/19
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Ken Ferry, 2004/01/19
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Ken Ferry, 2004/01/20
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Richard Frith-Macdonald, 2004/01/20
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Gregory John Casamento, 2004/01/20
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision),
Richard Frith-Macdonald <=
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Kazunobu Kuriyama, 2004/01/21
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Gregory John Casamento, 2004/01/21
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Gregory John Casamento, 2004/01/21
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Richard Frith-Macdonald, 2004/01/22
- Re: NSKeyedArchiver/NSKeyedUnarchiver (was Re: GModel decision), Kazunobu Kuriyama, 2004/01/22