discuss-gnustep
[Top][All Lists]
Advanced

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

NSKeyedArchiver support in GNUstep (was Re: RFC: Appreciation of .gmodel


From: Gregory John Casamento
Subject: NSKeyedArchiver support in GNUstep (was Re: RFC: Appreciation of .gmodel format (was deprecation))
Date: Sat, 10 Jan 2004 18:38:34 -0800 (PST)

Chris,

See below...  I would like us to implement NSKeyedArchiver/NSKeyedUnarchiver
support in GNUstep, if possible... read on...

--- Chris Hanson <address@hidden> wrote:
> On Jan 6, 2004, at 7:00 PM, Gregory John Casamento wrote:
> >> Because I can't exactly make out what you mean, let me ask a question.
> >> If the assertion above is true, -encodeWithCoder:/-initWithCoder: 
> >> which
> >> were written for a class designed to be used with 10.1 or before must 
> >> be
> >> rewritten for use with 10.2 or later.  Is this true?
> >
> > No. Your argument is predicated on the assumption that 10.2 uses
> > NSKeyedArchiver to encode nib objects, which is false.   10.2 
> > continues to use
> > NSArchiver to save and load .nib file objects.
> 
> Actually, his argument isn't predicated on that.  He's not talking (at 
> least in the above quoted paragraph) about nib archiving at all.
> 
> Here's the rundown:
> 
> (1) NSArchiver and NSUnarchiver are still supported in Mac OS X 10.2 
> and later, and work just as they did.  Same with the various 
> encode/decode methods of NSCoder that they implement.  Archives created 
> with these are referred to as "sequential archives."

I'm aware of this... :)
 
> (2) Mac OS X 10.2 adds NSKeyedArchiver and NSKeyedUnarchiver, and some 
> additional methods to NSCoder for encoding and decoding values with 
> keys.  It also adds a method -(BOOL)allowsKeyedCoding that indicates 
> whether or not a particular archiver supports keyed coding.  It's OK to 
> use the old-style sequential-archive methods with a keyed archive as 
> well.

Yes..

> (3) Mac OS X 10.2 and later support two formats of nib file.  The first 
> is "10.1 and earlier," which is an old-style sequential archive.  The 
> second is "10.2 and later," which is a new-style keyed archive.  Some 
> 10.2 and later classes have features that are only supported in keyed 
> archives (10.2 and later nibs).
> 
> (4) Keyed archives have both a binary and a textual (XML property list) 
> representation.  You can convert from one to the other easily using 
> /usr/bin/plutil, and the 10.3 version of Interface Builder even 
> includes a checkbox to let you easily save nib files in text format.  
> This doesn't, however, guarantee nibs can be differenced or merged or 
> anything like that, but it's a step in the right direction.
> 
> Since there are Cocoa developers using keyed archiving in their file 
> formats, it might be a good idea for GNUstep to eventually plan to 
> support it.
> 
>    --Chris

Actually, I think that once we have an implementation of the keyed archiver,
it's likely okay for us to move to this format.  Since the keyed archiver can
output to an XML format, we should make certain that the XML between the two is
as compatible as possible or, at the very least, that there is a simple
transform that can be appled to make it so.

We will still need to add code to all objects to allow them to be saved using
the keyed archiver, but this is a very small price to pay for this kind of
cross platform capability or at least to make the format human readable!! :)

Once we have it, it shouldn't be a big deal to add the support, it's just time
consuming since there are so many classes.  But I know I'd be happy to do it.
:)

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 
-- Main Developer of Gorm (featured in April Linux Journal) ---

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus




reply via email to

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