Re: Some somewhat cooler thoughts...

[David Ayers]

Gregory Casamento wrote:

> I partially agree, the problem as I see it, though, is that the two systems
> (MOSX/OPENSTEP and GNUstep) are incompatible when it comes to encoding *in
> general*.   If we use an open, human readable encoding format in NSCoder, that
> might help in the general case. 
>  
Sorry for budding in again, but if your reference to NSCoding (it would 
have to be something like GSCoding though.) means, that every class 
would be responsible for encoding what it *thinks* it needs and that it 
augments the super classes encoding as NSCoding does, then we would have 
implement categories to all Foundation and AppKit classes for OS X/4.2 
(in cross plattorm bunldes) and every custom class would have to 
implement this protocol in loadable bundels. These bunldes would then 
determine which information to encode, and which to leave out.  I'm not 
saying that this is necessarly bad but it would be only *one* way to 
encode object graphs into the .gsmarkup file format.  A Renaissance 
UI-Editor, on the other hand, may choose to put different information 
into the .gsmarkup file (not relying on GSCoding) and rely on the 
Renaissance framework to initialize a fully functional object.  In fact 
the User will have to tell the RUI-Editor which attributes to save and 
which to leave for the Renaissance library.

> This would mean that, since gorm files use the encoding model, that they would
> become human readable XML files or plists (whichever) and so would anything
> using a class which uses NSCoder to encode itself.
>  
>
> > P.S. I think gmodel files are obsolete. So that only leaves gorm and 
> > gsmarkup, which is not that bad...
> >    
> I think that gmodel files can still serve as a way of porting apps from
> OPENSTEP and MOSX which use nib files.  But, I also believe that they
> eventually should go away.
>
>  
Well actually I think everything currently encoded in the .gmodel format 
is representable in the .gsmarkup format.  (Independant of what the rest 
of the Renaissance-framework currently makes of it, so I agree with Adam 
that .gmodel becomes obsolete.)  That means to say, that the file format 
already just as easily supports the WYSIWYG paradigma of .nib/.gorm 
files.  The .gsmarkup format merely *allows* (a) additional layout 
information and (b) the omission of information which can later be 
enriched the by the parsing mechanism used (Such as Renaissance's 
autolayout mechanism for example.)

I would even go so far as to say that the .gsmarkup format could be used 
as generic a portable object archive (well actually it already is.)  But 
to be more concrete, there is nothing stoping us from writing a 
GDL2-gsmarkup extension library that include an 
EOGSMarkupArchiver/Unarchiver which would use EOModel information to 
arichve an enterprise object graph.  Of course feeding this file to the 
current Renaissance library would not be meaningfull (I guess give you 
the object graph in memory but no UI  representation).  But my point is 
that if you compile the this GDL2 extension against an EOF-App (which 
also implements the clases that are referenced in the .gsmarkup file) 
the object archive in the .gsmarkup file are fully poratable!

In fact maybe even a DO extension could be made available for plattform 
inependant interprocess communication.

Therefore it (the .gsmarkup format) can (theoretically) also replace the 
.gorm format as a plattform independant format., as long as we provide a 
set of plattform independant bundles, which implement the un/archiving 
categories. This would be similar to Renaissance but not necessarly 
Renaisance.

Yet I am fully aware that .gsmarkup files will be very much larger than 
typed streams and slower in parsing.  Both reasons would most likely 
exclude it as plausible replacement for DO and also justify the 
existence of typed stream formats like the current .gorm format.

And just to make it explicit, I *do* believe that Gorm.app should 
continue to create WYSIWYG files and that the RUI-Editor should create 
autolayout files, but the .gsmarkup format could be shared.  I don't 
know/think that either application would make a good editor for the 
other "type" of .gsmarkup file.  I'll even go further in suggesting that 
the file extensions could even denote which decoding mechanism a certain 
file would be intended for. (.gsmlGSCoding, .gsmlRenaissance or even 
.gsmlGorm)  All I'm saying is that that the way the format (or should I 
say the DTD) is currently defined, makes it an extremely versitile 
format for plattform independant object graph storage in general.

Cheers,
Dave