Monday, October 23rd, 2006

Clorox – Shared Memory Abstraction for AJAX Applications

Category: Framework, JavaScript

Take a step back and squint and you’ll see that Ajax, with it’s ability to pass structured data back and forth between client and server, can be used to implement just about any architecture or abstraction that involves communication between execution environments. The only things getting in the way are the platform and performance limitations of the browser. Even with this limitation, we’ve already seen implementations from the obvious RPC (DWR, JSON-RPC, etc.) all the way to X11 (XML11) and various client engines and protocols in between (TibCo GI, ZK, Echo2, JackBe, etc.). If you haven’t realized this already, there’s more than one way to do things with Ajax.

Now along comes Clorox, a different kind of abstraction on top of Ajax. Developed as an MIT class project (see the paper here), Clorox hides all of the asynchronous request business behind simple Javascript data structure access.

In place of the asynchronous, RPC-based abstraction furnished by AJAX, Clorox provides the illusion of synchronously-accessed data structures shared between the web browser and web server, which is to say, it provides a shared memory abstraction. These data structures look exactly like ordinary JavaScript objects on the client side, allowing programmers to focus on what they do best (writing compelling web applications) without worrying about data locality, message reordering, callback functions, or data prefetching. Additionally, to free programmers from concerns over locking, Clorox allows multiple operations on these data structures to be grouped into atomic actions.

Clorox is a client-side technology. You have to write the backend code — returning JSON objects with a TTL that controls caching — yourself. Clorox consists of the Javascript runtime (which incorporates MochiKit) and a compiler (based on Rhino) that transforms application Javascript to Javascript. Why this extra step of compilation?

The Clorox Compiler compiles Clorox JavaScript files (.cjs files) into plain JavaScript. Didn’t we just say that programmers write their applications in ordinary JavaScript, you ask? Yes, they do. However, under the hood, Clorox does have to make asynchronous AJAX calls to fetch data. The Clorox Compiler takes in JavaScript code that makes synchronous accesses to data structures and transforms it into JavaScript code that accesses the data structures using continuation-passing style programming. (This means that every time a data structure is accessed, we supply a method that indicates what to do after fetching the appropriate element). Essentially, this involves breaking up the code into a collection of callback functions. At runtime, these CPS accesses will generate the appropriate sequence of RPCs. In any case, installing the compiler is very easy. Just download it from the Clorox web site. It’s packaged as a single jar file, so there’s nothing else to do. It’s written using Java 1.5, so you’ll need a recent version of the Java Runtime to use it.

So you write code like this:

var cache = new ClientCache(new SimpleAJAXTransport(“/path/to/your/script.pl”));
var cs_array = new SmartArray(“basicArray”, new NoPrefetchPolicy(), cache);
function printNumbers() {
for (var i = 0; i < 100; ++i) { doWork(i); } } function doWork(i) { document.getElementById("outputDiv").innerHTML += cs_array.access(i) + " "; } [/javascript]

and the compiler turns it into some ugly stuff with callbacks that does all the Ajax stuff for you. Clorox also allows you to configure whether it prefetches values or not for improved performance. You can see the framework in action in a mapping demo and a search suggestion demo.

clorox.jpg

Right now Clorox is in Alpha and has only been tested with Firefox 1.5. The documentation is brief but serviceable but more code examples are needed to provide a good framework to start your own application. Future developments will include automatic cache tuning. As this toolkit evolves, it could become the foundation for other, higher levels of abstraction. ORM for Ajax anyone?

Posted by Dietrich Kappe at 6:00 am
7 Comments

++++-
4 rating from 18 votes

7 Comments »

Comments feed TrackBack URI

seems interesting … however suggest doesn’t allow me to choose showed results and mapping demo crashed 2 times on my FireFox 1.5 … and I’m not going to test them for the third time.

Comment by Andrea Giammarchi — October 23, 2006

So you’re saying it behaves like Alpha software? Help them out. Send them a bug report. FWIW, I haven’t experienced any crashes on Firefox, but then again I run a pretty vanilla install without many extensions.

That they haven’t implemented the ability to select the suggestions is, I think, documented on the demo itself. It’s early yet in project. Cut them some slack and make constructive suggestions.

Comment by Dietrich Kappe — October 23, 2006

I often do bugs report when I can but runtime errors (crashes) aren’t readable inside my console.

To reproduce my crashes just drag the map from right to left one or two times.

Comment by Andrea Giammarchi — October 23, 2006

Interesting Finds: October 23, 2006

Trackback by Jason Haley — October 23, 2006

A fundamental (but not insurmountable) problem you’ll see with this approach is the stack depth limit. The conversion to Continuation Passing Style (CPS) means that functions aren’t returning, but calling into a function (the continuation) to continue execution. In the absence of tail call optimization, the call stack gets deeper and deeper. Consequently, if you drag around the map a bit on Firefox 2, you’ll see that it eventually spits a “too much recursion” error to the JS Console and breaks (in a fairly fun way: you get to drag around the individual map tiles, rather than move the whole map). I didn’t see this reported in the documentation, but I’m fairly certain it’s a problem they’ll need to address in their compiler (by modifying it to do tail call optimization).

Comment by dak — October 23, 2006

Why you need to write a special extension to Javascript — which needs a special compiler and runtime environment and mozilla browser — just to implement the basic concept of data access abstraction in Javascript, is beyond me.

Can anyone explain why this is necessary, and why my basic client-side accessors with caches that refresh via http requests, don’t actually suffice?

Comment by Trav — October 25, 2006

[…] http://ajaxian.com/archives/clorox-shared-memory-abstraction-for-ajax-applications • • • […]

Pingback by sephi’s tips!»Blog Archive » Clorox - Shared Memory Abstraction for AJAX Applications — November 8, 2006

Leave a comment

You must be logged in to post a comment.