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

[Jed Donnelley]

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.

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.

At 09:15 AM 5/19/2008, Karp, Alan H wrote:
> >
> > Is there no way to describe the essential and core
> > capability concept and to provide for communication
> > of capabilities between different systems (language
> > or OS) without getting drawn into issues such as the
> > synchrony of the communication and the presentation
> > of the data parameters?
>
>Not unless you define a means to bootstrap the process or a means to 
>negotiate these things.

I don't have any problem with such a negotiation in principle,
but it still seems to me to require the awkward M x N**2 set of
mapping programs noted above.  Sure some code can be shared, but
I don't see how to avoid writing unique code to make any method M
in system A available in system B.

>The initial Client Utility protocol had such a bootstrap
>mechanism.  Negotiation was simple, "Initiator makes right."

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?

> > 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.

> > One of the nice things about capabilities
> > that we seem to be able to agree on regarding their semantics
> > is that they don't need to be separately "type"d (we have no
> > "integer" vs. "string" capability types - I believe).
>
>Yes, capabilities are just like opaque protected references.

Right.

> > I regard both these issues of the synchronous vs.
> > asynchronous (buffering, etc.) nature of the messaging
> > and the typing/interpretation of the data as
> > orthogonal (separate, non essential) to the core
> > of capability communication and would like to somehow
> > factor it out.
>
>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.

At 09:48 PM 5/19/2008, John Carlson wrote:

>It seems like marshalling and unmarshalling has been
>done many times, with such as things as Web Services, HTTP, MIME, EDI,
>CORBA, RMI, XDR/RPC,DCOM, JSON,
>Lisp s-expressions etc. etc.  No need to reinvent the wheel.  You just
>have to find something that everyone can read and write.  My personal
>favorite right now is JSON.
>
>http://en.wikipedia.org/wiki/JSON

Hmmm.  I agree JSON seems focused close to the right problem,
but I don't see a complete solution there and I also don't yet
see how it could avoid the combinatoric explosion of translations
between methods and systems.

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.

--Jed  http://www.webstart.com/jed-signature.html