Re: NSKeyedArchiver implementation...

[Gregory John Casamento]

Richard,

--- Richard Frith-Macdonald <richard@brainstorm.co.uk> wrote:

> 
> On 9 Sep 2004, at 19:45, Richard Frith-Macdonald wrote:
> 
> >
> > On 9 Sep 2004, at 19:13, Fred Kiefer wrote:
> >
> >> 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?
> >
> > Yes, my feeling too ... I would expect that producing archives in a 
> > new gnustep specific format and trying to use xslt to convert between 
> > that and macos-x format would be a *LOT* more work than just using the 
> > macos-x format to start with.
> 
> It occurs to me that it may not be obvious why this is so ...
> 
> If we want macosx compatibility at the end of the day, we have to 
> reverse engineer the macosx format in order to understand it.  This 
> work is required irrespective of the format we use.

True.

> So what we are concerned with is how we translate between situations 
> where the classes in macosx are not the same as the classes in gnustep, 
> and we have to perform some complex mapping between them.

Yes.

> While xslt is very good for performing translations on simple xml 
> element hierarchies, Objective-C is a much more powerful language and 
> can more easily cope with complex situations ... not to mention that 
> anyone writing this code *must* understand the objc classes in order to 
> know what the translation should be, and so will be familiar with using 
> objc (probably much more so than with xst|).

XSLT is good at pattern matching and translation.   It is much more natural for
changing XML from one form to another than most other languages.    In that
sense it's powerful.   There's no reason why it couldn't be used in the way I'm
suggesting.

> Also, the macosx archive format (as xml) is not designed for easy 
> translation using xslt (it's an xml representation  of a binary 
> serialization of a property list)

I'm convinced that even though it's XML it was never designed for easy
translation under any means.   We would, of course, need to unserialize,
transform and reserialize.

> so while we could design a 
> gnustep format to be easily handled by xslt, the translation would 
> still be horribly complex.

I never once said that the translation would be any easier with XSLT than by
doing it in the code.

My issue is that we will not only need to read, but we will also need to WRITE
the same format.  So we *will* need to keep up with IB and Cocoa changes, which
can only be done by those of us who have Cocoa machines.  This is particularly
a problem when it comes to .gorm archives (which are just object archives like
any other).  There are many internal classes which are vastly different and it
will be expected that if keyed archiving can read/write Apple archives that we
will also be able to read/write Apple .nib files (since they are also simply
archives). 

There are some things that have been done in GNUstep, particularly with
templates, which are superior to how Apple/NeXT implemented it on
MOSX/OPENSTEP.   I hesitant to reverse engineer this piece on MOSX, and others,
and change how we work and possibly degrade how we work simply so that we can
be compatible.

GJC

=====
Gregory John Casamento 
-- CEO/President Open Logic Corp. (A Maryland Corporation)
#### Maintainer of Gorm for GNUstep.