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

[Richard Frith-Macdonald]

On 22 Jan 2004, at 03:07, Gregory John Casamento wrote:

> Richard,
>
> --- Richard Frith-Macdonald <richard@brainstorm.co.uk> wrote:
> > On 21 Jan 2004, at 03:54, Gregory John Casamento wrote:
> <.......my previous email deleted.......>
> > 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.
>
> I wasn't referring to the existing format.   I am referring to making 
> keyed
> archives on GNUstep compatible with keyed archives on MOSX.   I've 
> stated why I
> think this is not advisable in previous messages.

Ok, I think I misunderstood.


> > 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.
>
> This is true.  I believe that we should at least look into the 
> possibility of
> doing it.
>
> > 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.
>
> I agree.
>
> My concern is mainly for some of the classes which make things work 
> behind the
> scenes, the custom class templates and other classes which are part of 
> the
> structure of a .gorm file.   There will need to be something in the 
> new code
> which will allow these to be transformed into their MOSX equivalents 
> and back
> again.

Yes ... but only IF you decide you want to make Gorm capable of loading
MacOS-X nibs and writing nibs readable by MacOSX interface builder of
course ... I'm not trying to force that on you (though I think a lot of 
people
would like it).

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

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

So I AM advocating complete compatibility when and where we implement
archiving for library classes via the keyed archiving api ...
If we want keyed archiving of library objects which is not MacOS-X
compatible (in the sense of MacOS--X applications being to read our
archives and vice-versa), then we should implement it using the old
keyed archiving api we already have ... and if we don't care about that
we should deprecate/remove the old api ... that's something we should
debate and decide upon.  My feeling is that, since we have never 
bothered
with keyed archives up to now, we have little/no need for keyed archives
other than for MacOS-X portability, and should remove the old keyed
coding api.

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