Re: NSKeyedArchiver implementation...

[Fred Kiefer]

Gregory John Casamento wrote:
> For the past few months some members of the team have been trying to implement
> keyed archiving in a manner compatible with MOSX.  This is difficult.  Here are
> a number of reasons why:
>
> 1) We need to reverse engineer each and every class in the class hierarchy.
> 2) We need to, in some cases, match or emulate the Apple class hierarchy.  
> This is particularly the case when with private classes.

Both of this points are true. But I cannot see, how they would be a big 
obstacle of implementing a keyed archiving for GNUstep that is 
compatible with MacOSX.
The reverse engineering of the normal classes didn't look to hard for me 
(and as far as I know I have been the only one doing this for GUI 
classes up to now). The only problem I encountered where the flag fields 
which get stored as integers, so we need to experiment which bit 
corresponds to which state variable.
The internal classes may be a bit harder, but I did not encounter too 
many of them. You already have my Archiver.m file which reads some of 
them. The only place where I did see bigger problems at that time was 
NSComboBoxCell where Apple stores an NSTableView, while GNUstep kept the 
field in an NSBrowser. In the meantime GNUstep has, for totally 
unrelated reasons switche to a table view here.
It may be different for the actuall NIB loading classes (e.g. 
NSIBObjectData). Apple doesn't use that many of them, but it is a bit 
hard to figure out, how they actually work.

Could you please name the classes where you see the problems?

> Using the archivers methods will be tricky to force some of this as many of the
> attributes in the hidden classes are, by necessity different.  So, I believe
> that it will be easier to use a tool more suited to the job.  What I believe is
> slightly better is to implement keyed archiving in our own way and provide a
> way to be compatible with MOSX, if necessary. :)
>
> We can do this by way of an XSLT transformation.   XSLT will allow a
> transformation from the XML format which is produced for Apple archives to be
> directly translated into XML needed for the NSKeyedArchiver/NSKeyedUnarchiver
> format.   This has serveral advantages:
>
> 1) It will allow us to complete the implementation of GNUstep's own XML
> formatted archives more quickly and in a less kludgy manner.
> 2) We will not need to rely on the limited nature of some of the tools which
> are provided in NSKeyedArchiver/NSKeyedUnarchiver for "translation" of Apple
> archives.
> 3) It allows us to make our XML implementation as robust as we wish without
> being bound by Apple's implementation.
>
> It should be possible for us to add some extensions to the API which will allow
> the user to specify a stylesheet to be used.  It may also allow some other
> types of things to take place in the transform which may be useful.

At first I thought of this as a very nice solution, doing our own stuff, 
while still being able to exchange with Apple applications would be 
great. It would even free us of update problems for either side, as 
incompatible changes would just result in small changes on the XSLTs.
Than I tried to imagine an XSLT for this and here my fantasy failed me.
So for example how would you transform any of the actual problematic 
bits you listed above?

Sorry, but my feeling is that this proposal would mean "lets do our own 
stuff now and care for Apple compatibility later", that is never. My 
question here is, what good would keyed archiving be, if it doesn't 
allow the exchange with Apple applications? Our current archiving format 
works quite well. Using XML in itself is by no means better, it just 
uses up more disk space.

If we spend any more developer time on this (up to now only Richard and 
I contributed here) it should be for the exchange with Apple systems. 
Everything else looks like a waste of time to me. But than, there may be 
something I am overlooking. I really would like to hear about that than.

And finally, once more the call for help:
Could somebody with access to a new Apple development environment help 
with decoding the bit fields? No actually programming skill is needed 
here, just access to the IB and an editor. Of if even this is asking to 
much, I am willing to write a short application to test the bits if 
somebody will execute it and send back the results.

Cheers
Fred