discuss-gnustep
[Top][All Lists]
Advanced

[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: Thu, 22 Jan 2004 10:19:58 +0000


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

Richard,

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





reply via email to

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