Re: NSKeyedArchiver implementation...

[Richard Frith-Macdonald]

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.

> > 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.

> > 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.

>  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.

>  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.

>  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...

> 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 ...

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.

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.