[E-Lang] Draft Kernel-E DTD & Sketch of translation to debuggable Java

Dan Bornstein danfuzz@milk.com
Wed, 27 Sep 2000 12:24:52 -0700 (PDT)

Mark S. Miller writes:
>In any case, I'm not advocating JOSS/RMI of course, but JOSS/Pluribus 
>http://www.erights.org/elib/object-pluribus/index.html , which is E-specific 
>in the above sense.  My immediate need for the converter is simply to help 
>me debug. But to accommodate current tastes, I may eventually allow the 
>connect-time protocol negotiation to negotiate to use the textual protocol.  
>Given the converter, it should be painless to support this. 

After having spent a large fraction of the last few months dealing with a
large distributed app that uses RMI for most of the IPC, I'll have to weigh
in that I have concerns about JOSS.

The short story is: If all you ever expect to send over the wire are
instances of classes that are already known to both ends (and are serialver
equivalent on both sides), then you're okay, but if you *ever* expect to
have one end be able to receive instances of a class it didn't already know
about, or receive instances of a class that are of a newer version than the
one it knew about, then forget about it. JOSS doesn't seem to provide any
particular support for that sort of thing. (The RMI layer sortakinda
tries, but it ends up falling pretty flat too.)

If it were me designing the wire protocol (and I know it's not), then I'd
do something more like design the XML DTD first, having it contain things
directly meaningful, and then construct the mapping from that DTD to
appropriate Java objects, which would have to be instances of globally
agreed-upon immutable-forever (at least in terms of their serialization
format) classes. The JOSS format would be the happenstance of how those
objects serialized, rather than the essential thing from which the other
formats would be derived. I'd say this arrangement would be a good thing,
since raw JOSS is pretty opaque (even when interpreted into human-readable
text) and seems a bit space on the space-inefficient side, especially given
that it's a binary format. (Actually, I wouldn't be surprised if many XML
expressions constructed this way ended up taking up fewer bytes than the
equivalent JOSS.)

Simple example: Let's say you had strings, ints, and vectors as types
you wanted to be able to directly represent, you might end up with
XML like this:


which would end up getting constructed in Java by the equivalent of this:

    v = new Vector ();
    v.add (new Integer (1));
    v.add ("foo");
    return v;

and would serialize in JOSS as "whatever a two element Vector consisting
of an Integer and a String happens to serialize into."