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

[Gregory John Casamento]

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.

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

I am aware of this.

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

Yes.

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

Yes, the existing code for non-keyed archives should be retained.   But, as
stated above I was, indeed referring to keyed archives.

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

GJC

=====
Gregory John Casamento -- CEO/President Open Logic Corp.
-- bheron on #gnustep, #linuxstep, & #gormtalk ---------------- 
Please sign the petition against software patents at: 
http://www.petitiononline.com/pasp01/petition.html 
-- Maintainer of Gorm (featured in April Linux Journal) -------

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/