untyped

Flapjax is the awesome functional reactive Javascript library from Brown PLT. We had a good experience with Flapjax some time ago, but in the interim it seemed that the project died. Turns out it was just hibernating. In the last few days Flapjax 2.0 has been released, along with a tech. report describing the system in more detail than the somewhat brief documentation.

To celebrate I coded up a small animation library for Flapjax. It’s hosted on Github, not our usual Subversion server as I wanted to gain a bit more experience with Git.

As a followup to The State of State on the Web I want to mention stateless servlets, a relatively new feature of the PLT web server that make continuations (even) more usable. Stateless servlets are essentially a kind of servlet with serializable continuations. A serialized continuation can then be stored on the hard disk, in the URL, in a cookie, or using any other mechanism you desire. This gets around the issue of memory consumption that is a concern with normal continuations. I don’t have a lot of experience with this kind of servlet, but Jay’s experience is that they are faster than normal servlets and the continuations are typically less than 100 bytes (and so can easily be encoded in a URL). Very nice!

There seems to be a miscomprehension that continuation based and RESTful web apps are mutually exclusive. Witness Nagare proudly proclaiming “no explicit URL routing / mapping … no global session object … no REST” as if continuation based frameworks were violently in opposition to these features. This is not the case. Fundamentally the issue is about managing state, and continuations, cookies, and friends are all approaches to solving the problem of encoding state over a stateless protocol. At Untyped we develop web apps that use a combination of continuations, RESTful URLs, and cookies for managing state and I believe this is the correct way to approach the problem. I hope this post will convince you of the merits of our approach.

Before looking at the tradeoffs of the different approaches I want to summarise continuations and their use in web applications. Simply put, the continuation of a program is what happens next. In the program (+ 5 (+ 2 1)) the continuation of (+ 2 1) is to evaluate (+ 5 []), where I’ve written [] to indicate the place where the value of (+ 2 1) goes. Now in Scheme we can capture a continuation, store it in a variable, and generally pass it around like any other value. This means we can effectively suspend a computation (by capturing a continuation) and then resume it at some time in the future (by invoking the continuation, which in Scheme appears as any a function application).

Now let’s look at what continuations do for web applications. A continuation-based framework associates a specific server state with a URL, which it does by capturing a continuation when a response is sent to a user. Everytime the user visits that URL they visit the same server state, invoking the captured continuation. As the user navigates around the site they build a history of server states that can be revisited using the back and forward buttons. This has several advantages. Firstly, if you don’t use mutation the back button will just work, because the user is just back to the same program state. Pretty neat. Furthermore, continuations give you procedure call semantics in your web app. Because a continuation is resumed when a URL is visited, to your program it appears as if the user’s request is the returned value of the function that sends your response. It’s as if you were using display and read on the web. This makes programming a lot simpler. For example, if you want to forward the user to a login page you just call the login page function, and it will return to the right place. No need to pass that page a URL to redirect the user to. This can be incredibly productive.

Now we’ve seen some of the advantages of continuations, we must consider the cases where the model falls down. There are two main issues: server load, and scope. Server load is simple. Every time you store a continuation on the server you use up some memory (RAM or disk space). At some point you have to reclaim that resource, so people may see “continuation expired” pages if they leave a long time between visits (though this is no worse that session expiry, which is quite common). Often a website has pages that are just displaying the results of simple queries to a database. These pages have no interesting state and using continuations in this case is wasteful of resources. Here RESTful approaches are appropriate, and we use them with, for example, the web server’s dispatchers.

Scope is another issue with continuation-based apps. Recall that continuation-based frameworks associate a particular URL, meaning a particular browser window (or tab), with a particular server state. There are some kinds of state that should be shared across all browser windows. Login information is a prevalent example. If I login to a site via one browser window, and then visit that site in another browser window I expect to already be logged in. This isn’t possible with continuations, as they are per window. Cookies, on the other hand, are per browser. So storing my login status in a cookie is the right thing to do.

In summary, RESTful approaches (URL routing, for example), cookies, and continuations are complementary and all have a place in web applications. Don’t think, for example, that is you use continuations you automatically reject everything RESTful! Finally, the Anton of Straaten addressed this issue from a different direction in his LL4 talk. Check it out for a different take on the problem.

Equivalently we could say the continuation of (+ 2 1) is (lambda (x) (+ 5 x)). This realisation is the key to continuation passing style, a program transformation useful in compilers and, perhaps surprisingly, AJAX web applications.

Ben Simon asks questions about web development using PLT Scheme. We answer!

• [W]hat kind of server do I need to reliably run this puppy? Any Linux VM will do to start with. We use Bytemark. Amazon EC2 is another option. I recommend installing PLT from source; don’t rely on your distribution’s package to be up-to-date.
• I wonder what kind of memory usage I’d want to plan for? It really depends on your application but as a guide we’ve run simple apps in 64MBs of memory.
• I’d have to test out PostgreSQL or MySQL db support to make sure it was strong. PostgreSQL is solid, MySQL is not.
• I’d have to sort out what the deployment cycle is like. Just copy over files and restart? Yes. Could I do hot deployment of some kind, by reloading scheme files (one of my favorite tricks in the book)? The web server does have some reloading functionality but we haven’t used it (no good reason; it just isn’t something we do).
• What’s the best production web server arrangement. The PLT web server is solid, but we usually proxy through Apache so we can take advantage of Apache’s flexibility should we need it.

Jay McCarthy, maintainer of the PLT web server, has started blogging about improvements he is making to the web server. Start reading here and go back through the last six or so posts. It is great to see the web server getting more visibility.

Google is releasing a browser, called Chrome and based on the WebKit engine (same engine as Safari). To introduce the browser Google has published a series of photographs of the Chrome developers at work, and got them to explain in their own words what went into the browser. This does a good job of showing that working at Google really is one sun-shine filled cartoon day after another, but good gracious does it make for tedious reading. Next time just give the technical details as a bunch of text, ok?

Anyway, here are my thoughts on Chrome:

• First, it has to be said: WE DON’T NEED ANOTHER BROWSER! Working around bugs in existing browsers takes enough time as it is. Google would have to create a truly exceptional product to gain enough market share to make developing from Chrome worthwhile. The only hope for Chrome, at least in the short term, is that it is attractive enough to developers that they use it as their main browser, and so are motivated to make their web apps support it.
• Perhaps Chrome is going to be Google’s development platform for Android, it’s mobile phone platform. As we’ve said before there are squillions of web developers and harnessing them is the easiest way to get developers for your platform. Offer extended APIs (e.g. saving data to the local machine) using this familiar technology and you might be onto a winner.

• If Google’s follows the route suggested above I could see Chrome getting some use for developing client-side applications. In theory Firefox is a compelling environment for cross-platform development. In practice the horrors of XUL and friends mean you have to be slighlty insane to go down that route. If Chrome does a better job of enabling client-side development I can it gaining some traction.

Many years ago I started the Scheme UK user group in merrye London Towne, and all was good. Then I moved to Birmingham and Scheme UK slowly died. I always had the intention I’d start it up again when I had more time, but now I don’t have to! Ewan Higgs has taken the initiative and organised the next meeting for the 28th of May. Dave Griffiths will be talking about his fairly awesome fluxus system. All the details are on the Scheme UK site.

The Biographicon is a very pretty web site of user contributed biographies. It is also written in Scheme, and here’s one of the developers discussing how it was done.

We’ve just released a package called Instaservlet, which enables you to get a servlet running in two lines of code, plus the servlet code. Here’s a simple example:

  (require (planet "instaservlet.ss" ("untyped" "instaservlet.plt" 1)))

(define (servlet request)
'(html (head (title "It's working!"))
(body (h1 "Instaservlet is in the house!"))))

(go! servlet)

Try it in PLT Scheme 3.99 and see!

This package arose out of the development work I did on Smut Shorts, which made me I realise we needed to support a quick start for web development. Instaservlet is the first step in doing this. Not only does it setup the servlet, it does it in a robust manner. Continuations are managed using the LRU manager, which can be a bit difficult to setup but it much more robust than the time-out manager. Instaservlet uses some sensible defaults which should work for most small to medium size sites — they’re the setting used on Smut Shorts, so we know they can handle a reasonable load. It also sets up a nice default page to handle continuation expiry. Instaservlet is good enough to get you started with, and future versions will enable more customisations so it can scale to any website build using PLT Scheme.