🚀 go-pugleaf

I am contemplating how best to save an application's info, that is
its document formats.  I had assumed that the best way to save
objects would be to override the appkit archival methods and read and
write objects using NXReadObject() and its like.  However, a
comment in the 3.0 version of the Draw program in
/NextDeveloper/Examples/AppKit/Draw/DrawDocument.m indicates that
this produces documents which are incompatible between system versions,
and should not be used in third party apps.  Here is the comment
section of DrawDocument's save method:

- save // line 1116
/*
 * Writes out the document in three steps:
 *
 * 1. Write the printInfo object
 * 2. Write the frame of the window
 * 3. Write the GraphicView itself.
 * 4. Write form information if necessary
 *
 * See GraphicView's write: method for more details on how the GraphicView
 * is archived.
 *
 * Note the "This is questionable" line.  It's questionable because it  
means
 * that Draw documents saved under a particular SYSTEM version can really  
only
 * be opened under the same SYSTEM version no matter which version of DRAW
 * writes the file.  In other words, if we take 2.0 Draw on a 3.0 system  
and
 * save a file, that file will NOT be able to be opened with the same  
version
 * of Draw (2.0) on a 2.0 system.  The bottom line is that archiving  
Application
 * Kit objects as part of the file format of your documents ties the user  
forever
 * not only to the version of Draw that saved the file (obviously you  
cannot open
 * a file saved with Draw version 3.0 with Draw version 2.0--that's okay,  
we'll
 * accept that restriction), but also to the version of the system  
(meaning a file
 * saved with Draw 2.0 may not be openable by Draw 2.0 if the save and  
read don't
 * occur on the same version of NeXTSTEP).  Since Draw is always  
"re-released"
 * (for free, no less) whenever new versions of NeXTSTEP are released,  
this is
 * probably okay for Draw, but probably IS NOT OKAY for 3rd party  
applications!
 *
 * The right way to do it is just to have the GraphicView write out its  
data
 * directly to the typedstream (i.e. don't call NXWriteObject on the  
GraphicView,
 * just call a method you invent called writeToTypedStream: in  
GraphicView--your
 * implementation of writeToTypedStream: in GraphicView must remember to  
explicitly
 * write out any instance variables of View that need to be saved and  
restored
 * when the document is saved and reopened).
 *
 * The writing out of the PrintInfo object is more problematic.  There is  
no real
 * way for you to know how to write that out yourself.  NeXT will have to  
be careful
 * not to change the archiving of this object in an incompatible way  
(backwards or
 * forwards).
 */

It does not seem correct that one should have to create a duplicate suite
of archival methods in order to have documents that can be read
on any version of the system software.  Can any of you who have
experience with maintaining application documents verify that
using NXWriteObject() is not the way to save application objects?

Thanks,
Scott
--
Scott Stark
University of Delaware
Department of Chemical Engineering
123 Colburn Lab
Newark, DE 19716-3119
(302) 831-6713