Re: NSKeyedArchiver implementation...

[Gregory John Casamento]

Hey,

--- Fred Kiefer <fredkiefer@gmx.de> wrote:

> Gregory John Casamento wrote:
> > 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.
> 
> I understand the problem with writing Apple compatible NIB files. But 
> perhaps we should just not put this at the top of the priority list? 
> Mine looks like this:
> 
> 1) read Apple object archives
> 2) read Apple NIB files
> 3) write Apple object archives
> 4) write key code GNUstep GORM files
> 5) write Apple NIB files

That seems reasonable.

> That is, first get all the normal classes to be read in. Than the 
> special NIB classes from Apple. Later we may start to support writing 
> object archives and than key encode our own GORM classes (and of course 
> add reading for them as well). Last we may try to be able to write NIB 
> files that could be read in on a Cocoa system.
> If we ever get to step 4, but not to 5, we could simple ship a small set 
> of GORM classes in source code to be used on Cocoa systems.

I hadn't considered that approach.   We could have a framework utilized by
Cocoa  applications which would allow them to be read.  

> Fred

What mainly concerns me is the overall cost of keeping up with Apple.   We
don't have the manpower/resources, indeed, we are not a company with millions
of dollars and thousands, or at least hundreds ;D, of employees, which can do
this.

I'm concerned that when Apple comes out with 10.4 and 10.5, etc, etc.. it's
going to be an exercise in reverse engineering again.   It would be cool to
find some way to simplify the process of reverse engineering, but failing that,
I see this effort taking a long time, unfortunately.

GJC

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