[cap-talk] contemplating Waterken + X3D--synergy

Stiegler, Marc D marc.d.stiegler at hp.com
Tue Mar 17 14:11:04 EDT 2009


> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of John Carlson
> Sent: Sunday, March 15, 2009 10:16 PM
> To: General discussions concerning capability systems.; X3D 
> Graphics public mailing list
> Subject: [cap-talk] contemplating Waterken + X3D--synergy
> I am contemplating using the Waterken Server,  
> http://waterken.sourceforge.net/ to produce a served X3D 
> (read web3d) web application.   The last time I played with 
> Waterken, it looked you would program a Java API, and its 
> objects and methods would be exposed as XML, with which you 
> could use stylesheets to transform them into an HTML 
> application.  Now, it looks like it exposes JSON (but I 
> haven't confirmed this), which can be transformed using 
> JavaScript (or some version of Caja) on the client side, and 
> Java on the server side (actually, Joe-E, from what I've read).
> I guess my question is, how different is Waterken since I 
> last used it?  It looks like it has moved from a REST-ful API 
> to a ref_send API which looks interesting.  I can really see 
> how X3D Routes are like Promises--good stuff--Is there a Java 
> or JavaScript API for X3D Routes that can be merged with the 
> ref_send API?  Does anyone else see a similarity between 
> Routes and Promises?

Waterken is substantially different now from the old system that used XML on the wire and created web pages using XSLT transformations. As you have perceived, it now uses JSON on the wire, and JavaScript on the client side to create the web page. The JavaScript ref_send library supplied with waterken makes it easy for JavaScript objects to interact with server-side Java objects with a high-level promise pipelining abstraction. Client-side programmers never have to see xml or json or http requests or posts or gets, it's all just message-passing objects -- a huge leap forward from the basic AJAX approach. The ref-send library is Caja-compatible, so you can enforce caja confinement on client side objects. The waterken server itself is compiled under Joe-E discipline, and server-side applications can also be built under Joe-E discipline, though frankly the SCoopFS system violates enough Joe-E rules that I do not compile it under Joe-E: an inadequate number of authorities have been tamely integrated into the waterken framework to make an application like SCoopFS straightforward to implement. Having built SCoopFS I am now finally getting a clear idea on how to integrate tamed authorities into waterken, the environment is sufficiently different from the capdesk and emily and E environments, I spent a lot of time stymied on the question of what it would mean to integrate ocap authorities.

The biggest problem with waterken at this point is probably the near-perfect absence of documentation. This is my fault, I've been promising tyler documentation for over a year now, but it keeps being not-quite-highest-priority. Despite this, a couple of people have successfully used the server to build prototype applications, starting with the example apps distributed with the server and scrutiny of the source code.


More information about the cap-talk mailing list