Alan Kay in the News

Mark S. Miller markm at
Tue Apr 30 16:30:05 UTC 2002

At 08:46 AM 4/30/2002 Tuesday, Cees de Groot wrote:
>Thanks :-). I'm subscribing to the mailing list, 

Glad to have you aboard!  I'm cross-posting this message to both lists, but 
let's continue the discussion on e-lang.

>but just to fill me in: is
>there any work on making sure that vats from multiple languages can
>communicate? That'd be really neat...

Well maybe it doesn't yet qualify as "work", but here's a snippet of 
conversation from e-lang:

I wrote:
>> Might it be possible for a Squeak "vat" to speak CapTP and interoperate (at 
>> vat granularity) with E vats?

Rob Withers wrote:
>I don't see why not but Java serialization would be an issue.  I was
>going to go with a generic serialization framework, using smalltalk
>serialization (one of many versions), then look at building java
>serialization.  As you can imagine, this is a big task.

I wrote:
>Let's start by trying to agree on a relatively platform neutral textual 
>serialization based on term trees.  We can then later discuss a binary 
>equivalent, and evaluate Java serialization as a candidate format.  We are 
>committed to having adequate connect-time negotiation to accommodate these 
>even if we can no longer drop our current serialization.
>By platform neutral, I include neutrality from Java vs other implementation 
>platforms for E, but not neutral regarding E vs Squeak.  Rather, let's 
>proceed as if your efforts were to result in an E implemented in Squeak 
>(Squeak-E).  We want disparate implementations of E to be able to speak 
>to each other anyway (eg, ENative/CapScript (E on C++), CapSharp (E on 
>.NET)), so this may be a good way to get our feet wet.

The E protocol, Pluribus, comes in two levels: VatTP, described well at and CapTP, barely 
described at .  All the 
serialization issues below occur at the inadequately described CapTP level.

The current status is that I owe Rob a message explaining our Term trees.  
I'd love to hear any other thoughts on "platform neutral" serialization.

1) By "platform neutral" I don't mean that it can't favor or be based on one 
platform (such as Squeak), but rather that it not impose a level of pain on 
other platforms significantly beyond what a truly neutral format would 
impose.  For example, Java's RMI, despite all its faults, is a better 
"platform neutral" system than Corba.  While RMI is built to support Java 
specifically, it is less painful for other platforms than is Corba.  Corba 
imposes similar pain on everyone, and that level of pain is higher for
everyone.  I'm more interested in standards which reduce the general level 
of pain than in ones which allocate pain "fairly".  A platform independent 
system, like Corba, is just covertly yet another platform, and usually one 
less well designed than the platforms it's trying to be independent of.
So don't be shy about proposing Squeak-based or Parcels-based serialization 

2) From previous discussion on e-lang, I feel we must have both a textual 
and binary serialization format, designed together, or one derived from the 
other, such that conversion in either direction is meaning preserving.  A 
connection will start out textual, and will switch to binary only after a 
text-based negotiation about how to proceed.  That way we enable text-only 
processors (humans on a telnet) to play.

3) Both formats must provide good support for upgrade (or class evolution).  
Java serialization, for all its awful complexity, does this, and I'd like 
one that does at least this well.  My understanding is that Parcels does an 
excellent job at upgrade, but I'm much less familiar with it.

4) The textual format must be human readable and human editable.  This 
combined with the "meaning preserving in both directions" requirement means 
that one can edit a binary serialization graph by translating to text, 
editing, and translating back.  Likewise, it enables a logger to log binary 
network traffic as binary, and then later present it as textual if there's 
interest.  An edited textual log can then be used as a basis of test

5) The binary format must be able to perform reasonably.  My understanding 
is that Parcels is unmatched here on reading speed, but I have no idea what 
price it pays on writing.  For CapTP's use, each graph will be written once 
in order to be read once.  For persistence use, many more graphs will be 
written (one per checkpoint) than will be read (one per revival).  Both of 
these are different than the tradeoffs Parcels was optimized for.

6) Both formats must be simple, and easy to document.  Java serialization 
fails this test.

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.

Text by me above is hereby placed in the public domain


More information about the Squeak-dev mailing list