Ian tried commenting here, but it apparently didn't work - that Javascript form may be more trouble than it's worth. Anyway, to the meat of his new post: he says that I missed his point, by assuming that by "resources" all he meant was memory. Based on his original post, that is how I took it. However, he explains further, and lists resources that GC doesn't typically handle: database connections, sockets, (etc, etc).

Here's why I didn't consider that - because all of that is at issue in any web app that maintains some kind of session state on the server. Whether you use continuations or cached data in some other form, you end up dealing with all of that (unless you re-open everything on each submit - which tends to get expensive). Typically, you use the finalization mechanisms of your language/library of choice to deal with that: the session times out, finalization kicks in, and you clean up. I fail to see how continuations make this more (or less) complex.

As to this on the back button amd continuations:

I'm not claiming that it's impossible to handle the back button this way. I'm just saying it's a bad idea, because you need to be able to write code that can tolerate being wound back and forth at the user's whim.

That's precisely the complexity that continuation based servers remove from your purview. In a "standard" we app, you tend to toss some kind of page key around, so that you can tell where you are (as opposed to where your app thinks it is on the server). How that's simpler, I have no idea. Having written a number of web apps in the standard way, I'm not prepared to call it simple.

Via Don Box, I see that Ian Griffiths has a few issues with continuation based web applications. One issue he brings up is resource usage:

Sometimes the user just walks away. I might get part way through the purchasing sequence on a web site and then decide to stop. The web server never gets any positive indication that I closed the browser window. It merely stops hearing from me.

What does this mean in a world where I’m using continuations to help model user journeys as sequential code? It means that sometimes my functions just stop part way through without reaching the end.

On the plus side, it is predictable where this will happen: it can only occur at boundaries where I choose to construct a continuation and then relinquish control for now. But at every such boundary, I need to be aware that sometimes, the continuation will never execute.

This is very much not analogous to the function returning or throwing an exception. In the world of our chosen abstraction - that of sequential execution of a method - it looks like our thread has hung.

The problem with this is that a lot of the techniques we have learned for resource management stop working. Resource cleanup code may never execute because the function is abandoned mid-flow.

I don't know why this would be a problem, given a halfway decent GC system. The stale session will eventually time out, and take any lingering state down with it. I can see being worried about the memory required by this, in the face of a lot of users, but not in the basic mechanics. In a Smalltalk server - either VisualWorks or Squeak based - Ian's worry is a non-problem. Then he has an issue with thread affinity:

Traditionally, any particular invocation of a function runs on a single thread from start to finish. We’re not accustomed to mid-function thread switches, and it will render some hitherto safe practices unworkable. Using objects with thread affinity will become particularly hazardous, for example - we will need to be mindful of the potential switch points and make sure we never use such objects across such a boundary.

Actually, in this server, I've got requests that end up invoking new processes now, without continuations. They are managed with a class called Promise, but it's pretty simple - it's just a matter of delaying the waiting process and using a signal to inform the waiting process that results are ready. The pre-existing class makes that easy for me, but the code isn't hard to follow either way. Running multiple threads with shared objects is a comlex problem for any kind of application, whether continuations are involved or not.

Then he's got a long riff on how Continuations might break in the face of the Back button. Hmm - that was one of the problems that this approach was designed to solve. So far as I know, this simply isn't a problem in Seaside.

Seems the Java guys are starting to realize that there are simpler ways to solve problems - this weeks JavaCast talks about Seaside, amongst other things. Very cool.

Sam Ruby gives a nice summary of them - especially useful for people who aren't that familiar with Smalltalk or Ruby.

Via Learning Seaside comes a pointer to a PDF presentation on Seaside - and I'm quoted on the first page :)

Chris Double reports that Avi has set up a new Seaside site. Also notable - the Seaside license has changed over to the MIT license.

Torsten reports that Brett Taylor has written up a Seaside experience report (PDF).

Look at all the links to Continuation based web apps gathered on Planet Lisp. Looks like a trend.