As a former WebObjects programmer and NextStep fan, I like the non-xml
plist format.  Its dead simple but very powerful.

dictionary is { key1 = value1; key2 = value2; key3 = "Some text on\ntwo
lines."; }
list/array is ( one, two, "Complex string" )
or its a string.  Any nesting of the above is possible - you can create
oids if you like to do cross linking but the basic plist format is very
powerful and you can do a parser in a few lines of code.  I use it
constantly from java :-( these days.

-----Original Message-----
From: Cees de Groot [mailto:cg at cdegroot.com]
Sent: Tuesday, April 30, 2002 11:28 AM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: Alan Kay in the News


Mark S. Miller <markm at caplet.com> said:
>So don't be shy about proposing Squeak-based or Parcels-based
serialization 
>formats.
>
Braindump:

- SRP (State Replication Protocol) is a Smalltalk-platform-neutral
protocol with some nice properties, and is expressly meant to be usable
on platforms besides Smalltalk. Especially the data encoding is cool,
but
apart from that it also has good support for class evolution, etcetera.
http://wiki.cs.uiuc.edu/CampSmalltalk/About+State+Replication+Protocol+(
SRP)

- Python has a neat serialization format that is based on some sort of
mini-language which has textual and binary representations, support for
custom formats and things like oid-replacements. Jim Fulton (Zope and
formerly Smalltalk) thinks it is usable from other languages as well.
The
pickle.py module is less than 1000 lines of code.

- I wouldn't suggest XML - all the code doing the XML parsing is
probably
too large for anything security-related. 

- RMI would be doable in Smalltalk, I think; it's well specified and
the people behind RMI know what they were talking about so IMHO it's
an OK wire protocol. The multiplexing makes it quite efficient from a
resource-usage point of view. As you remark, Java serialization is a tad
complex, so this might be a big job.
http://java.sun.com/products/jdk/1.1/docs/guide/rmi/spec/rmi-protocol.do
c.html
http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/seria
lTOC.doc.html

- The Parcel format is VisualWorks specific, although it probably could
be
ported (the problem is that the format has no formal specification
AFAIK, so a
'port' would almost certainly mean having to read code from VisualWorks,
which
brings you in muddy legal waters).

Even though I haven't followed the conversation on the E list on the
necessity
of a text format, I dissent. I think that if you want a human to talk to
a
running E instance through telnet you would better open a separate
connection
with a minimal command language (maybe one that would allow you to
specify an
object, step by step, and then you enter the "send" command).

>7) The format must be compatible with our security requirements.  In 
>particular, since E is only prepared to trust mobile E code, any need
for 
>executable code in the serialization format must be E code.  Parcels as
is 
>fails this test of course.
>
In the context of heterogenous E implementations, the point of mobile
code
becomes tricky, of course :-)

-- 
Cees de Groot               http://www.cdegroot.com
<cg at cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B