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

[Rob Meijer]

On Thu, May 8, 2008 21:11, Kevin Reid wrote:
> On May 8, 2008, at 13:47, Jed Donnelley wrote:
>> On 5/8/2008 4:30 AM, Kevin Reid wrote:
>>> ...
>>> Note that VatTP as it is today will be going away when the Pluribus
>>> implementation is rewritten in E; the encryption layer is to be
>>> replaced with SSL. There will still be a layer on top, to support
>>> delimited variable-length messages and PING messages.
>>
>> Doesn't that "layer on top" also have to distinguish serialized
>> capabilities and other parameters with semantic meaning (e.g. strings,
>> integers, etc.)?  I ask in case I might be focusing at the wrong
>> point.
>
> No, CapTP handles that part.
>
> Pluribus ~= CapTP . VatTP
>
> VatTP-old = <custom stuff>
> VatTP-new = <lighter custom stuff> . SSL

I have two questions:

1) Is there a specific reason why SSL, not TLS was chosen for this ?

2) Would the stack lend itself also to local IPC mechanisms? Unix domain
sockets, with the ability to pass Fd's between processes over these
sockets would seem like an efficient local IPC based alternative to
loopback networking and SSL. It would be very interesting to know if CapTP
could locally be stacked on top of a Unix domain sockets version of VatTP
?

Rob