[etoys-dev] Current project serialization format?

[Yoshiki Ohshima]

  Andreas,

At Tue, 01 Dec 2009 10:59:53 -0800,
Andreas Raab wrote:
> 
> Quick question: What is the current project serialization format used in 
> Etoys? Historically, image segments were used but I know that Yoshiki 
> looked at alternatives and I don't know what the current state of 
> serialization in Etoys is.

  For regular projects, we still use good old ImageSegments.  The
alternative is an S-expression representation (dubbed "SISS", homage
to SIXX) that is used for the QuickGuides contents.

  The reason for using SISS for QuickGuides is that ImageSegment is
faster for bigger projects than SISS, but for smaller projects SISS is
faster and (tends to be) smaller.

  Also with SISS, there is somewhat better control over the Player
classes (it knows which classes are from it), so loading and unloading
a Guide book is easy.

> Specifically I am interested in:
> - Does an Etoys project file contain any sort of Manifest that states 
> version dependencies? (i.e., says which version of Etoys it was created 
> with)

  Yes. There is a file called manifest in the zip and it looks like:

Squeak-Version: etoys4.0
Squeak-LatestUpdate: 2325
File-Name-Encoding: utf-8
Project-Language: en
URI: http://squeakland.org/etoys/yoshiki-3431931444
user: yoshiki
Project-Format: ImageSegment
projectkeywords: fractal, chaos
projectcategory: 553
projectname: Mandelbrot
projectdescription: Mandelbrot set drawing
projectauthor: 

> - Is the current Etoys project serialization format a low-level format 
> (like ReferenceStream, ImageSegments etc) or a high-level format (more 
> abstract description; not directly serializing bits of the underlying 
> object)

  Since the default is ImageSegment, the answer is "a low-level".
Even SISS is (more or less) in text, the field description is still
tied to the actual instance variables of these objects by default.
So, migrating objects to another system or adding skin to the UI is
not entirely made easy (though possible).  One good thing about the
SISS version is that the "identical" project usually produces exact
the same result; so tracking the change was easier.

  There was a bit of attempt to provide a higher-level format in SISS.
It involved like when there is no TransformationMorph, its
renderedMorph's bounds is in global coordinates, but once
TransformationMorph is added the it becomes in local.  A higher level
description should be uniformly dealing with one of them (probably
local), but it wasn't really to a point where one can save and load a
project.  For Etoys, any UI object is potentially scriptable and
reshapable(so far, people may want to restrict it), so it is another
stumbling block for it.

  For a completely different project VPRI are doing internally, I
store UI objects in SISS in more higher level description of UI
objects and already went through some major object shaping
successfully.

> - Assuming it isn't image segment based how are scripts and script 
> references implemented? Same as previously (file out for scripts, class 
> vars or globals refs for references) or differently?

  In the ImageSegment, at least the references are made project local;
the dictionary of player reference name to actual object is in the
property of PasteUpMorph and the script compiler looks up objects from
there.  But otherwise it is similar to before.

  In SISS, a script is saved as a "parse tree" out of send node,
repeat node, variable node, etc.  It roughly look like:

  (script :name "script1" 
     (send :selector "color:sees:"
         (variable "self)
	 (Color "....")
	 (Color "....")))

or such.  The Player class names and internal names of Players are
abstracted away.

> Thanks for any info. I haven't looked at project serialization in many 
> moons so I'm definitely not up to speed here.

  Well, I regard that you are still the expert when it comes to
project saving in various forms....

-- Yoshiki