evolution of CapTP -- Re: Fwd: Chat with [email protected]

On Saturday,2009-09-19, at 10:04 , Mark Miller wrote:

> There are four protocol transitions CapTP needs to make.

Several of these changes seem to make CapTP become closer to Foolscap  
[1] (which was originally inspired by CapTP).

We rely heavily on Foolscap in the Tahoe-LAFS project, so I would be  
interested to see if Foolscap and CapTP can evolve to be closer to  
one another over time.

> * Switching from our custom DataComm to a VatTP layered on top of TLS.

Foolscap has always relied on TLS for its crypto.

> * Switching from Java serialization, as used by E-on-Java, to Data- 
> E, as used by E-on-CommonLisp and Caja-CapTP.

Foolscap's serialization isn't Data-E, but I guess it is slightly  
more like Data-E than it is like Java serialization.  ;-)

> * Dropping the SwissHash from the live reference protocol as  
> discussed in this thread.

Hm, I don't know about this one.  Brian Warner is the author of  
Foolscap -- Cc:'ing him to ask if this makes CapTP more Foolscappish.

> * Change the exposed object APIs (esp the Miranda Methods) to  
> something more language neutral, as already adopted by Caja-CapTP,  
> so that Caja-CapTP and E-CapTP can interoperate better.

And this one, too.

By the way, Foolscap includes a logging system with Causeway-inspired  
causality tracing.  If you are using Python (the only language that  
Foolscap supports), you should definitely check it out.

Regards,

Zooko