[etoys-dev] Current project serialization format?

Ted Kaehler Ted at vpri.org
Wed Dec 2 15:13:59 EST 2009

Andreas, Yoshiki,
	As the author of the current ImageSegment-based project 
storing (with Dan Ingalls), and as the author of the two infamous 
error messages when loading a old project, I need to point out a few 

>  What I really want to do is
>  to provide enough information so that a project loader can tell whether
>  it will be able to load a project and if not, why, instead of our old
>  friend  "Reading an instance of GobblyGook. Which modern class should it
>  translate to?" which is my second-favorite questions to ask users. (of
>  course my absolute favorite is when project saving invites you to "stop
>  and take a look" at some blocks it encountered - both are completely and
>  utterly incomprehensible questions to users that it's pointless to ask
>  them in the first place)

(I certainly hope that those two infamous error messages are not my 
legacy to history... )

The only important questions is, "Would you rather have an error 
message when you are trying to save a project, or when you are trying 
to load it?"  The frustration and anger of not being able to save the 
work that you just did is unspeakable.  On the other hand, not being 
able to load an ancient project just means that you need to go get a 
few definitions before you can proceed.  There is no comparison of 
the urgency of saving vs loading.

Fixed-format systems like SISS, and many XML-based systems, cannot 
cover everything.  You can always create some data structure or code 
in your project that cannot be written out.  There is no universal 
format.  A universal format is not possible.  The only thing we can 
do is provide enough levels of indirection so that anything can be 
expressed in a saved project.  (Maybe a universal format is possible, 
and maybe we should invent it.)

I am glad that I sit next to Yoshiki, because when I can't write out 
my window in our new LObject world, I just turn to Yoshiki and ask 
him to fix SISS.  I highly recommend this way of working to all 
future project creators.  A bit impractical, though.

The current ImageSegement-with-address-space project saving has a 
much wider range of what it can save.  It can save any data 
structure, period.  It keeps the names of instance variables in the 
entire tree of superclasses.  A project can survive a huge set of 
changes in instance variables in classes.

Yes, there is a problem with rare "naughty blocks" (a highly 
technical term of art), but I will fix that if there is demand. 
Please note that SISS can't store ANY blocks at all.

One goal of SISS-style formats is that a human can read it.  In an 
emergency, a person can look in the file and see what objects are 
there.  Having readable text in the file also helps other people 
write translators to other systems.
        Hypercard's file format is ascii and is human-readable.  Bill 
Atkinson did this deliberately, and used it to debug code and repair 
stacks by hand.  I watched him do this, and my conclusion is that it 
was a total waste of time!  Every minute he spent poking around in 
the innards of a stack was a waste.  It is much better to make a 
binary format that works completely, and never look at it again.  I 
followed this technique with the ImageSegement based saving, and it 
has worked well.

If we insist on a text-based file format, parsing will play a vital 
role.  I suggest that we get Alex Warth involved.

Once again, let me ask, "Would you rather have an error message when 
you are trying to save a project, or when you are trying to load it?"


Ted Kaehler
(home) 3261 Montecito Drive, Las Vegas, NV 89120.  voice (702) 456-7930
Q:  How do you warm up a room that has just been painted?
A:  Give it a second coat.
(from National Geographic Kids, via my nine year old son)
Q: Why is a dog like a man?
A: Because he wears a coat and pants.
(the favorite joke of my grandfather's friend, except he got mixed up 
and said trousers instead of pants, which made it even funnier.)

More information about the etoys-dev mailing list