I took some time and looked at the CDR format and tried to equate it to 
the E message format.  A CDR defines a request (regular, lookup, 
cancel) where there is some header info (msg type, byteorder, request 
id) and then a receiverId, an operation, and arguments.   There are 
specific encodings defined for each of these...they are almost all 
integers or bytes/string

In an E "DeliverOp" message, there is a command code (DeliverOp), a 
receiverId, a selector (or verb), arguments.  There is also an 
answerIndex and a reader, I believe.  The problem is that all of this 
is serialized using a java serializer, which squeak doesn't have one of.

The CDR request format (GIOPMessage), probably doesn't map into CapTP, 
but it does have a standard encoding of this header info.  Maybe we 
could create a GIOPCapDeliverMessage, etc.   All of the arguments could 
certainly be CDR encoded, but CORBA also needs to exchange operation 
signature definitions, so we can unmarshall the objects correctly.   
WOS also requires a doc-code, it seems.


On Saturday, January 18, 2003, at 08:59 PM, David Chizmadia wrote:

> Robert,
>
>> The one serialization format that jumps to mind is CORBA.
>
> As the resident CORBA advocate on E-Lang :-), I agree completely
> that the CORBA CDR (Common Data Representation) specification is
> a strong open and neutral starting point for data encoding and
> serialization in CapTP.
>

glad to hear it, David.  I think there may now be two advocates  :)


regards,
rob