[I am cross-posting to both lists]

Last night, I successfully established a negotiated connection between 
an E Vat and a Squeak-E Vat.  Either side can be the initiating 
connection (outgoing).  While this is a huge milestone for us, there is 
still a fair bit of work to make Squeak-E's vat feature complete, and 
to implement the CapTP layer.    There has been a long list of 
contributers to this effort.  Thanks to you all.

My goal is to bridge E and Squeak-E so that they can interoperate and 
synergize.  There is just a tremendous amount of potential energy 
between the two communities.   The remaining barrier to a technical 
integration is a serialization format that would allow both to exchange 
objects.  It should be easy to come up with the minimum list of object 
types that we should be able to serialize in order to provide basic 
interoperability.  For starters: 	Numbers, Collections, Strings, 
Symbols, and Exceptions.

Here are some serialization criteria that I have in mind, some of which 
are implementation requirements, while others are feature requirements. 
  This is just a stab in the dark, so if you have any ideas that would 
help make this more solid, let us hear it.

1. it should be a binary representation for performance and scalability 
reasons
2. it does not have to be human readable
3. it should be easy to define new encodings
4. it should be easy to register mappings for new types
5. it should be a standard, if possible

While I like WOMP, and I am sure that many squeakers on the XML side of 
things would too, for my purposes I would like a binary format.  It is 
only for machine consumption, so readability isn't a criteria.   I 
don't have a link to WOMP, unfortunately.

The one serialization format that jumps to mind is CORBA.  There are 
language serialization bindings for Java, Smalltallk, C, and C++ (and 
probably others).  Since CapTP is specific to the kind of system that E 
is building, it may not map to the CORBA concepts of BOA, IIOP or GIOP. 
   Be that as it may, the OMG serialization standard is useful in its 
own right.

Comments and code are most welcome.

thank you,
robert