[cap-talk] OO interoperation via OCap, presentation level issues

[Baldur Johannsson]

Sorry for not responding earlier than this.

2008/5/20 Jed Donnelley <capability at webstart.com>:
> At 09:19 AM 5/19/2008, Baldur Johannsson wrote:
>>19. may 2008 Jed Donnelley <capability at webstart.com>:
>> > At 02:54 PM 5/16/2008, Baldur Johannsson wrote:
>>...
>> > I ask mostly because I believe it matches my thinking, even going
>> > back to the DCCS in 1975.  Although there:
>> >
>> > http://www.webstart.com/jed/papers/DCCS/
>> >
>>I have read that paper and that is where I "stole" the idea from ;D
>
> :-)  Nice to see some concepts have a bit of staying power.
>
Good concepts are more useful (have more utility) and therefore
are likely to be used more often.

> Still, it seems to me that some sort of a presentation level
> "header" (at least) for the data block is needed to facilitate
> inter "vat" communication.  I seem to get stuck in imagining
> the need for what amount to active translation libraries
> for "mapping" interfaces between OCap systems, where each
> method M in each of N systems needs a translation program -
> seemingly an M by N**2 coding nightmare.
>

Header as in C .h files?
As in record layout (which bits belongs to which datums)?

Or might each datum prefixed by an type-tag byte/nybble?

> You lost me in the above.  Can you explain what code handles
> such negotiations?  Can you imagine Client Utility methods
> being used by Coyotos (or E or Caja or ...) programs?
> If so, how would that work?  Do you believe this approach
> avoids the combinatoric coding problem that I'm concerned
> about?
>
>> > The other half of my frustration you only briefly
>> > mentioned when you touched on the topic:
>> >
>> >>Do you mean type as in designating those particular bits are to be
>> >>treated in that way?
>> >
>> > This is what I refer to as the "presentation" level where
>> > one must deal with data representations for "types" of
>> > data such as integers, strings, booleans, and perhaps
>> > more complex types. -snip-
>>
>>Seems CapIDL* fits this criteria nicely.
>
> Of course in some sense CapIDL was what I was trying to avoid, but
> still I'm happy to see it.  Perhaps I should spend a bit more time
> there.  Does anybody believe CapIDL could be a basis for
> serialized inter-vat communication between OCap languages/OSs?
> Does it suggest a means of avoiding the M x N**2 coding
> problem I suggest above?
>
The M x N**2 problem can be lessened by adaptors/translators chaining.
(sexp -> xml -> yaml -> json and so on.)

>> > I gloss over this my writing "Take" when such could be
>> > an integer or a string "opcode" and the index would nominally
>> > be a natural number.  -snip-
>>"Opcode"? I would have used the word "method name" or am I misunderstanding
>>something here?
>
> You have it.  Method names just have to be serialized like all
> other (network) communication.

As an string/symbol I expect.

> - snip -
>>Well if capability communication is like the act of speaking
>>then what is said is formed by an spoken language and
>>when to say it is controled by protocol.
>
> I'm sorry, but you lost me in the above.  If you think it
> important please elaborate.
>
Capability communication is delivering the message while
semantics describe how to interpret what the message means.

> - snip -
> Do others on this list accept the "Object" definition from JSON:
>
>>Object (collection of key/value pairs, comma-separated and enclosed
>>in curly brackets)
>
> to satisfy the OCap need?  To me it seems to widely miss the mark.
>
it doesnt as JSON "objects" are lua tables, python hashmaps and tcl
association arrays.

JSON would need one additional data-type called reference to allow it
to be used for ocap.
(in systems where the message is two blocks: caps and data the
reference would just be index into the caps block)

Without wax.
-Baldur Jóhannsson