[cap-talk] Union of runtimes (was: I Recant)

[Tyler Close]

MarkM asked that I send a response to this email, so I am doing so,
but I must warn in advance that I am not able to participate more
fully in this thread right now. I am over committed at the moment.

On 1/17/07, Jonathan S. Shapiro <shap at eros-os.com> wrote:
> On Tue, 2007-01-16 at 16:20 -0800, Mark Miller wrote:
> > For distributed client-server applications, when the server is
> > defensively consistent...
>
> The phrase "when the server is defensively consistent" is exactly the
> place where my reaction becomes "true but devoid of practical content
> from the developer perspective" [note I should have written "developer"
> earlier].
>
> You are always careful to add the qualifying phrase, which I greatly
> appreciate. My problem with it lies in the concern that this qualifying
> phrase reduces the set of currently interesting programs to a set of
> size zero. The mintmaker is a nice example, but it is a toy example.

I have been creating interesting, defensively consistent software for
many years now. With early versions of the Waterken Server, I built
sophisticated market abstractions that were defensively consistent
with respect to clients interacting with them over the network. I
demonstrated a stock market application, with derivatives trading, at
the First Edinburgh Financial Cryptography Conference in 2000. I got
the best presentation award that year.

> On reflection, the issue that needs to get talked about here is "Well,
> what is the impact of adopting defensive consistency as a design model?
> How does this narrow the set of useful and needed applications that we
> can build?" Note: I do not mean "how are must the actions of these
> applications be narrowed". I mean: "taking the real application
> requirements as immutable, which applications can and cannot be built
> within the defensively consistent model?"

I am currently working on an updated version of the Waterken Server
which is defensively consistent with respect to Joe-E code running in
the same JVM as server objects. This code will be the subject of a
week long security review next month. I believe the reviewed API
enables the implementation of defensively consistent Joe-E objects. I
further believe the API has wide applicability. The Waterken Server is
itself now implemented in Joe-E code, written to the proposed API. The
Waterken Server is a fully functional application server, implementing
HTTP, RDF/XML messaging and persistence. The HTTP, RDF and XML
implementations all conform to the IETF or W3C specifications, as the
case may be. Obviously I did not set these application requirements,
but I have faithfully implemented them in defensively consistent Joe-E
code. This version of the Waterken Server is again Open Source and
will be available for analysis and use following the security review.

> Also, what would be the cost of rebuilding these applications where
> needed, and more importantly, do we understand enough about the
> construction idioms to start teaching some of them to programmers?

I wrote the Waterken Server myself, so the cost of rebuilding typical
web application infrastructure with defensive consistency is
empirically known to be potentially low. I don't know how easy it will
be to teach others to work this way. I've gone through multiple
iterations of the API, always aiming for easier, safer idioms. The
upcoming API is remarkably easy compared to the first version. Maybe
this will finally be the iteration that crosses the threshold.

Tyler

-- 
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/