Re: NSKeyedArchiver implementation...

[Gregory John Casamento]

Richard,

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

> 
> On 10 Sep 2004, at 14:00, Gregory John Casamento wrote:
> 
> > 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.
> 
> Of course it *can* ... but I suggest you try using it for a few 
> examples of the sort of
> situations where transforming between class layouts in ObjC is 
> troublesome, and
> I think you will see what I mean.

No need.   I know from looking at it that it will be difficult.    My only
point was that, in the same way that lexx/yacc are better for language
translation/compiler building, XSLT is better for handling XML transformation.

I am, however, not stuck on XSLT as a solution.   It has several drawbacks, the
most prominent of which is it is not a turing-complete programming language.

> >> 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.
> 
> I'm not sure what you mean by 'unserialize' ... the xml document is one
> serialized form.  The unserialized form is a network  of objects in 
> memory,
>
> so a transformation of the unserialised for would be done in objc rather
> than with xslt.

I believe we're getting confused on terminology.   When I said "serialize" I
meant the "compressed" form of the XML archive, i.e. the non-xml keyed archive,
not the objects themselves and the reverse when I said "unserialize".  My
apologies.

What I was referring to was directly manipulating the XML into one form or
another, whichever language that entails using.

> >> 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.
> 
> Yes of course.  That doesn't seem relevant to the issue of whether to 
> use
> xslt or not though as we have to translate in both directions whatever 
> formats
> and tools we use.

This response to Fred had nothing to do with that. :)   I was simply pointing
out that reading the format is one thing.   We can take what we need from it,
but writing out the format is something different.  It might require us to
generate, derive or default data which we don't have.

> >  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.
> 
> Yes.  However, apple has to maintain compatibility in it's own nibs,
> so that's not a major issue.

We will always be lagged.   That's the issue with this.  Additionally, the
people involved in updating the code will need to have MOSX.  

> >  This is particularly
> > a problem when it comes to .gorm archives (which are just object 
> > archives like
> > any other).
> 
> There is no reason why gorm archives should use NSKeyedArchiver ...
> they don't do so now and they work fine.  If you mean that the 
> translation between
> nib and gorm formats is complex/difficult, I quite agree ... which is 
> why it
> needs to be done in ObjC if it is to be done.

Whatever is the easiest way. :)  The only sticking point with me has been that
we will be archiving in a format which doesn't always directly map to our
implementation.   That makes me feel uneasy.

> >  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).
> 
> I think that's what people would like to see...

Yes.

> > 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.
> 
> The fact that there is work that needs to be done if gorm is to 
> read/write apple NIBs
> doesn't mean you or I have to do the work ...

IF we get it to read any and all classes from Apple, I would, of course like to
make sure that it can read NIBs.   Again, if this is the case, I would not mind
doing the work.

> I really think this is a non-issue -
> 
> If you want to be MacOS-X compatible, the work is inevitable.
> If you don't want to be MacOS-X compatible, you don't have to do the 
> work.
> 
> Nobody is demanding that you work to make gorm macosx compatible.

It would seem the next logical step.

> Fred and I have worked on macosx compatible keyed archiving as an
> aid to general macosx compatibility should anyone wish to use it.
> Nobody is forced to use it, but we don't want anyone to break it for 
> others either.

I understand this motivation, I'm only concerned about the time it will take to
get there.

GJC

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