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

[Richard Frith-Macdonald]

On 20 Jan 2004, at 02:18, Gregory John Casamento wrote:

> Richard,
>
> > 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.
>
> I believe that, while direct compatibility would be nice, it has the 
> following
> problems:
>
> 1) We would not be directly archiving the structures in our classes 
> and would,
> instead, be "reconstructing" information when unarchiving or 
> "constructing"
> Apple compatible information when archiving.

Yes.

> 2) As with Apple's implementation, GNUstep also has some classes which 
> are
> hidden which are used inside the .gorm file/within classes which are 
> archived.
> This means that we'll have to know about any and all hidden classes in 
> .nibs to
> be able to effectively do this.   We would also have to be able to 
> transform
> the hidden classes we're using into the appropriate ones on MOSX.

Yes.  Though I think that's really  much the same as point 1.

> 3) Only people who have MOSX would be able to modify the code which
> encodes/decodes information in the archive in GNUstep.

Well ... you would need to test/compare with MacOS-X to ensure 
compatibility,
but I think there are plenty of people who would be willing to run test 
programs
on MacOS-X for people wanting to modify the classes who don't have a 
copy.

> 4) We would constantly be playing catchup with Apple, if they change 
> their
> encoding.

Yes ... like with all cases of attempting to provide MacOS-X 
compatibility.
I think the encoded representations of MacOS-XD classes are likely to 
have
a degree of stability comparable with that of the API.

> I believe that the correct place for any kind of MOSX<->GNUstep 
> nib/gorm level
> compatibility belongs in an application or a tool which is 
> specifically made to
> transform between the two.
>
> There are just too many differences between the implementations of 
> each to
> justify the effort of doing it directly in GNUstep's classes.

My understanding is that Kazunobo pretty much volunteered to attempt to 
write
compatible encoder/decoder code for keyed archives.  Certainly there 
seem to
be people who would like this level of compatibility.

I don't need it myself, but I'm attempting to make the keyed 
archiver/unarchiver
classes capable of being used to read/write MacOS-X archives if the 
coder/decoder
methods available support it.  To do otherwise would be to place an 
unnecessary
barrier in the way of people who do want archive compatibility.