Alan Kay in the News
Mark S. Miller
markm at caplet.com
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:
>> 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.
>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
http://www.erights.org/elib/distrib/vattp/index.html and CapTP, barely
described at http://www.erights.org/elib/distrib/captp/index.html . 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