[cap-talk] testing install of Waterken server before WWW 2008

Tyler Close tyler.close at gmail.com
Thu Apr 17 12:38:49 CDT 2008

On 4/16/08, Jed Donnelley <jed at nersc.gov> wrote:
> That seemed to work fine.  If that's where you are pointing,
> then it seems to me just a little clarification will do the
> job.  As I noted, I did my testing on a Windows OS and used
> cygwin tools for my build.  Naturally other environments will
> be different.

Looks like you made it through to the point I was hoping you would get
to. I'll add some more instructions to the documentation to help with
the stumbling blocks you pointed out. Thanks for the run through.

> Here's some feedback on the demo/tests:


> The examples seem a bit dry to me.  Testing message sending and
> replies for a single incrementing method strikes me as a
> topic only a developer could love.  I hope that's where you're
> focusing your presentation.

The focus of the presentation is on promises and how they make it
easier to implement algorithms that make multiple network requests.
The presentation is for developers who likely have their own
web-applications that do network requests. The counter is just there
to give us something to talk to, the focus is on how we talk to it.

> One thing I don't understand is the connection between the
> Javascript shell and the underlying waterken server.  Superficially
> the waterken server looks just like a Web server.  How is it
> these Javascript "commands" interact with the back end waterken
> server?  I'd be interested to see some sort of a diagram or
> discussion about how those two pieces communicate, particularly
> with regard to authority.

Answering the above questions will be the core of the presentation. I
plan to run through the Javascript commands you exercised, to
demonstrate the syntax and semantics of promises. During this demo,
I'll also have Firebug running in the browser, which provides an
on-the-wire view of the bits being exchanged between your browser and
the Waterken server. After the syntax walk-through, I'll then go over
the commands again, this time pointing out the corresponding network
requests. This part of the presentation will answer questions about
the communication of information and authority. I'll then go through
this example again, but this time in Java instead of Javascript, using
the code in org/waterken/bang/Main.java. The goal here is to show the
corresponding Java syntax for promises and to show communication
between two persistent vats, as opposed to a browser and a persistent
vat. I'll have the new Causeway event logging turned on during this
run, so that afterwards I can open up the event trace in Causeway and
explain about event loop turns and message pipelining.

At the end of the presentation, the audience will have seen the same
basic promise operations in four syntaxes: Javascript, HTTP, Java, and
a semi-graphical presentation of the message exchanges in Causeway. I
think I can get all that done in the alloted 15-20 minutes and then
take questions for 5-10 minutes. My hope is that the audience walks
away thinking that promises provide a light-weight syntax and easily
understood semantics for dealing with network requests. Hopefully they
will then download the Waterken server and use it to construct more
interesting applications than a counter. Although if history is any
guide, they will more likely implement promise libraries for their
current favorite toolset.

> In light of the Caja development I'd also be interested to hear
> about how the interaction between the Javascript interpreter
> and the waterken server compares to what would/will happen with
> Caja code interacting with a waterken server.

Right now the Javascript code in the browser is free to use all the
authority given to Javascript code by the browser. Caja would allow
you to restrict this and perhaps mix code from multiple sources in the
same way as Joe-E lets you do with Java in the Waterken server.


Use web-keys for RESTful access-control:

Name your trusted sites to distinguish them from phishing sites.

More information about the cap-talk mailing list