Limits of continuation passing web programming

[david.hilton]

I'm fairly sure most around here are familiar with component based/continuation passing style stateful web programming. If not, there's a reasonably decent overview of one specific framework http://www.defmacro.org/ramblings/continuations-web.html.

I've had some basic theoretical exposure to this style of programming, but how scalable is it? If memory serves, it is *very* possible for one user to use many objects, most of which would end up floating around for a while with no hope of ever being accessed (garbage collection is pretty tricky when we can't tell what the user has linked to). Of course, computer's capabilities are constantly expanding, something like AllegroCache could help handle more objects, and perhaps some sort of optional browser extension could help the site know what links may have been stored (for garbage collection).

Are there any (largish) sites that use this sort of stateful web programming?

[findinglisp]

This is a really good question. I don't know of any really large (e.g. consumer-oriented, Web 2.0) sites that use continuations. Many of the largest sites have specifically adopted simple REST APIs to provide themselves the highest scalability. It's my belief that most of the sites using continuations are smaller, corporate sites that have a known, limited user base and can afford the luxury of a continuation-oriented web design. That said, I don't know that for sure. I'd be very interested in hearing any counter-examples, where people know of a consumer-oriented site that is using continuations in any big way, and in particular if it's scaling well.

I wrote about this exact topic in a couple of posts on my blog. You might find them interesting. I had at least one discussion with Marco Baringer, the author of UnCommon Web, about whether continuations scaled. Marco was for it, at least for places where it worked. I was skeptical and thought you'd run into problems sooner, rather than later. A lot of it comes down to what the word "scale" means to you. If that's 1000 concurrent users, then something like continuations probably works. If that's 100,000 concurrent users, then it probably doesn't.

Personally, I come from a hardware background and I tend to think in terms of state machines anyway, so the advantage of being continuation-based isn't as big of a deal in terms of how I would structure a program anyway. For instance, frameworks like Rails or Django fit my mental model quite well.

Here are the links:
http://www.findinglisp.com/blog/2004/11 ... story.html
http://www.findinglisp.com/blog/2004/12 ... -rest.html

[skypher]

In my experience continuation-based style has a narrow application domain, e.g. in the implementation of “Wizard”-style dialogs.

Otherwise I'd go for request-based interaction anytime. It's bookmarkable and offers the user the experience he is expecting (stuff resetting when she reloads the page, etc.).

[findinglisp]

On wizards, yes, exactly. The problem with doing a whole web application with continuations is the explosion of state storage. At some point you have to limit that state by either throwing it away when the user reaches a given point in the program where it no longer makes sense to "go back" or after a time out. At those points, all the benefits of continuations cease. So it's a limited tool, IMO.

On the other hand, REST just scales. Period. You can't do any better because there is no server state other than the resources themselves, which always have to be stored there, otherwise you wouldn't have an application of any sort.

[doublec]

In a previous job I worked on a continuation based web framework written in Scheme. It was used to build a drag and drop, user friendly, authoring system for intranet style applications that ran in the browser. During the development of the system I had to work on a number of issues involving scaling. I definitely say that scaling to large numbers of concurrent users was a challenge.

The main issue we had with scaling was that we were serializing all continuations to disk. I used SISC Scheme running in the JVM which allows serializing and deserializing continuations. So each page request would result in at least one serialization or deserialization of a continuation. These varied in size from 10Kb to 1Mb. The tuning for scaling was mostly to stop the serialized continuation containing more state than we needed.

Using a continuation based approach did enable easier end user programming. The end user wrote in a simple procedural style language that was transformed to Scheme at compile time. The idea being that those used to constructing apps in a VB like system (eg. access) could write code like (psuedo code, not the actual language used):

Code: Select all

  while some_condition
    show page1
    show page2
    if var1=x
      show page3
    else
      show page4
    end
  end


[attila.lendvai]

about "going back": the back button of the browser is a very limited tool for navigation. once you write something that resembles more like an application (as opposed to a simple "website") you'll need smarter widgets for navigation (i.e. local back buttons that only affect portions of the page).

from our experience full continuation based web programming was the source of more trouble than gain. originally we used UCW, but now we have written our own framework that only supports the notion of different frames (browser tabs/windows) but no back button. it tells the user to forget the browser's back button when they try to use it. this sounds lame, but it's the result of our real world experiences.

our applications themselves provide much better navigation commands and also, because of their complexity, going "back" sometimes doesn't mean anything sane (e.g. after you impersonalize a different user, which alters your persistent authenticated session and with that your effective permissions... what would it mean when you press the back button to go back to the previous page that was rendered while the user had different authorization rules applied to her session?)