<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4913.1100" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>>From: <A
href="mailto:cg@cdegroot.com">cg@cdegroot.com</A> (Cees de
Groot)<BR>>Reply-To: <A
href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</A><BR>>To:
<A
href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</A><BR>>Subject:
Re: Alan Kay in the News<BR>>Date: 30 Apr 2002 20:27:59
+0200<BR>><BR>>Mark S. Miller <<A
href="mailto:markm@caplet.com">markm@caplet.com</A>> said:<BR>> >So
don't be shy about proposing Squeak-based or Parcels-based serialization<BR>>
>formats.<BR>> ><BR>>Braindump:<BR>><BR>>- SRP (State
Replication Protocol) is a Smalltalk-platform-neutral<BR>>protocol with some
nice properties, and is expressly meant to be usable<BR>>on platforms besides
Smalltalk. Especially the data encoding is cool, but<BR>>apart from that it
also has good support for class evolution,
etcetera.<BR>>http://wiki.cs.uiuc.edu/CampSmalltalk/About+State+Replication+Protocol+(SRP)<BR>><BR>>-
Python has a neat serialization format that is based on some sort
of<BR>>mini-language which has textual and binary representations, support
for<BR>>custom formats and things like oid-replacements. Jim Fulton (Zope
and<BR>>formerly Smalltalk) thinks it is usable from other languages as well.
The<BR>>pickle.py module is less than 1000 lines of code.<BR>><BR>>- I
wouldn't suggest XML - all the code doing the XML parsing is probably<BR>>too
large for anything security-related.<BR>><BR>>- RMI would be doable in
Smalltalk, I think; it's well specified and<BR>>the people behind RMI know
what they were talking about so IMHO it's<BR>>an OK wire protocol. The
multiplexing makes it quite efficient from a<BR>>resource-usage point of
view. As you remark, Java serialization is a tad<BR>>complex, so this might
be a big
job.<BR>>http://java.sun.com/products/jdk/1.1/docs/guide/rmi/spec/rmi-protocol.doc.html<BR>>http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/serialTOC.doc.html<BR></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I am currently working on reading in Java
Serialized Files as we speak into <BR>Squeak. Right now, I have simple
serialized java objects working (in other <BR>words, they don't override the
serialization interface (custom serialization) nor implements
<BR>externalizable), but I should have that working soon. <BR><BR>The
specification becomes very grey in places (look at the definition of <BR>values)
and they duplicate some information. It's not very well organized <BR>and it's a
bit of a mess. <BR><BR>I was doing the serialization to get RMI working in
Squeak. My plan is to <BR>have a Java program talk to Squeak without ever
knowing it's a non-Java <BR>program. I know there are several issues with this
(mainly, how to read in a <BR>Java class and have it execute and the reverse
being true as well). But, my <BR>plan was to run Squeak possibly as a JINI
service. I'm also helping work on <BR>the JXTA Smalltalk port project as well.
<BR><BR>Just remember Java serialization is yucky as a format...it seems half
cooked <BR>to me and thrown together to me. <BR><BR>Right now, it's a weekend
project for fun. But, if anyone is interested in <BR>seeing the Java
serialization code...I would be more than happy to send it. <BR>Warning: It's in
a state of flux...no tests and no comments yet. But, I plan <BR>to rectify that
situation soon...=) <BR><BR>P.S. Java serialization also changed with 1.3 (they
write out proxies <BR>differently as well) <BR></FONT></DIV>
<DIV><BR><FONT face=Arial size=2>>- The Parcel format is VisualWorks
specific, although it probably could be<BR>>ported (the problem is that the
format has no formal specification AFAIK, so a<BR>>'port' would almost
certainly mean having to read code from VisualWorks, which<BR>>brings you in
muddy legal waters).<BR>><BR>>Even though I haven't followed the
conversation on the E list on the necessity<BR>>of a text format, I dissent.
I think that if you want a human to talk to a<BR>>running E instance through
telnet you would better open a separate connection<BR>>with a minimal command
language (maybe one that would allow you to specify an<BR>>object, step by
step, and then you enter the "send" command).<BR>><BR>> >7) The format
must be compatible with our security requirements. In<BR>>
>particular, since E is only prepared to trust mobile E code, any need
for<BR>> >executable code in the serialization format must be E
code. Parcels as is<BR>> >fails this test of course.<BR>>
><BR>>In the context of heterogenous E implementations, the point of
mobile code<BR>>becomes tricky, of course :-)<BR>><BR>>--<BR>>Cees
de
Groot
</FONT><A href="http://www.cdegroot.com"><FONT face=Arial
size=2>http://www.cdegroot.com</FONT></A><FONT face=Arial
size=2> <</FONT><A
href="mailto:cg@cdegroot.com"><FONT face=Arial
size=2>cg@cdegroot.com</FONT></A><FONT face=Arial size=2>><BR>>GnuPG
1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098
9E8B<BR>><BR>------------------------------------------------<BR>Blaine
Buxton<BR></FONT><A href="http://www.mp3.com/blainebuxton"><FONT face=Arial
size=2>http://www.mp3.com/blainebuxton</FONT></A><BR><FONT face=Arial
size=2>"Think! It ain't illegal yet."-George
Clinton<BR></FONT></DIV></BODY></HTML>