Re: Fwd: Chat with [email protected]

On Thu, Sep 17, 2009 at 10:11 AM, Thomas Leonard
<tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]> wrote:
> Hi Mark,
>
> That's good to hear. Will the new version be backwards-compatible? How
> stable is the protocol?
>
> One thing that is slightly bothering me is that it doesn't seem to use
> SSL/TLS. I found this page:
>
> http://www.erights.org/elib/distrib/vattp/SSLvsDataComm.html
>
> but it is dated 1998. I think I will have a hard time trying to convince
> people that E's custom system is secure / will be updated if problems
> are found. It would make my life easier if I could just say it uses the
> Java SSL libraries for transport layer security.

There are four protocol transitions CapTP needs to make. Given the
current minuscule adoption, I'm inclined to make all four changes
simultaneously and not worry about compatibility.

* Switching from our custom DataComm to a VatTP layered on top of TLS.
Tyler and Kevin have both made progress towards this goal.
* Switching from Java serialization, as used by E-on-Java, to Data-E,
as used by E-on-CommonLisp and Caja-CapTP.
* Dropping the SwissHash from the live reference protocol as discussed
in this thread.
* 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.


> Anyway, thanks for a wonderful language! I'm surprised it seems so
> little-known.

You are quite welcome! Part of the reason for its obscurity is that,
once the ideas achieved a certain level of maturity, most of our
efforts since then have gone into adapting these efforts to other more
mainstream languages. E has had an enormous influence on Joe-E, Caja,
and EcmaScript. EcmaScript 5 is not an ocap language, but it is a much
friendlier base for Caja-like secure ocap subsettings. Going forward
after ES5, the EcmaScript committee seeks to make EcmaScript Harmony
an even friendlier base.

Goal 5 of <http://wiki.ecmascript.org/doku.php?id=harmony:harmony> says:
> Support a statically verifiable, object-capability secure subset.

Given that JavaScript is deployed on a platform used by more than a
billion people, it seems like a high leverage distraction.

Nevertheless, E remains important as the "scouting party" for
exploring the design space unburdened by legacy. The ideas we are
bringing to Java and EcmaScript respectively, we could never have
figured out in those contexts due to these legacy distractions.



-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM