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 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 formats.
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 cases.
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
Cheers, --MarkM