Java Serialization Re: Alan Kay in the News

Blaine Buxton bbuxton at kc.rr.com
Tue Apr 30 22:44:12 UTC 2002


>From: cg at cdegroot.com (Cees de Groot)
>Reply-To: squeak-dev at lists.squeakfoundation.org
>To: squeak-dev at lists.squeakfoundation.org
>Subject: Re: Alan Kay in the News
>Date: 30 Apr 2002 20:27:59 +0200
>
>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.doc.html
>http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/serialTOC.doc.html


I am currently working on reading in Java Serialized Files as we speak into 
Squeak. Right now, I have simple serialized java objects working (in other 
words, they don't override the serialization interface (custom serialization) nor implements 
externalizable), but I should have that working soon. 

The specification becomes very grey in places (look at the definition of 
values) and they duplicate some information. It's not very well organized 
and it's a bit of a mess. 

I was doing the serialization to get RMI working in Squeak. My plan is to 
have a Java program talk to Squeak without ever knowing it's a non-Java 
program. I know there are several issues with this (mainly, how to read in a 
Java class and have it execute and the reverse being true as well). But, my 
plan was to run Squeak possibly as a JINI service. I'm also helping work on 
the JXTA Smalltalk port project as well. 

Just remember Java serialization is yucky as a format...it seems half cooked 
to me and thrown together to me. 

Right now, it's a weekend project for fun. But, if anyone is interested in 
seeing the Java serialization code...I would be more than happy to send it. 
Warning: It's in a state of flux...no tests and no comments yet. But, I plan 
to rectify that situation soon...=) 

P.S. Java serialization also changed with 1.3 (they write out proxies 
differently as well) 


>- 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
>
------------------------------------------------
Blaine Buxton
http://www.mp3.com/blainebuxton
"Think! It ain't illegal yet."-George Clinton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20020430/d2062764/attachment.htm


More information about the Squeak-dev mailing list