[etoys-dev] Current project serialization format?

[Yoshiki Ohshima]

  Hi, Ted,

  (If there is a subsequent message, we should take it off line as it
is getting out of the etoys scope...)

  It is trade-off and I don't think I can convince you to change your
mind over night^^; Still, I'd think you agree that being able to "what
it logically means", instead of "how it is represented" opens up more
possibilities on one hand.

At Wed, 2 Dec 2009 12:13:59 -0800,
Ted Kaehler wrote:
> 
> 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.)

  SISS also can store all instance variables and all bits, and that is
what we basically do for now.

  Either in binary or text (it really doesn't matter; what matters is
the abstraction level that means how much it depends on the physical
representation of objects), and either the level of abstraction, the
interpretation of these externalized bits is provided by outside
environment, so yes, completely universal format that describes self
contained semantics is not what we are after.

  And also it is true for Etoys that such restriction has conflict
with the idea itself.  (Although with ImageSegment, some things are
deemed outside of the project being saved and left out from the
externalized file, like a script for viewer category and Thread
navigation morph.  Saving the image itself is an option for some
cases.a different project, etc.,

  Yes, so like you suggested (get a compatible image), or Andreas
suggested some long time ago (download the compatible environment from
the net and run the project in the environment), may be one way.  But
when people want, manifesting the logical meaning is cleaner, even
with some restrictions.

> 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.

  Hehe, actually it can.  What it cannot deal with is a block with
free variables; i.e., if block is printed in text without losing
information, it can be recreated upon loading.

> 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.

  Another goal is to take "diff" between versions and see what has
changed.  I really haven't needing edit the generated result to fix
something, but it certainly help debugging a thing completely works.

  BTW, I'm not sure many types of errors we had for that internal
projects are inherent to the way we did it.

> 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?"

  In either case, it may be still losing information when cropping out
a part of the data structure, there is line drawn upfront and if the
user is completely free to do anything, there is always possibility to
cross the boundary.

  So, we can make it so that it does not complain upon saving, but which
is easier to gurantee whether loading will work is still debatable...

-- Yoshiki