webapp state continuations

I went through some of the Rife web site pages recently. Rife is one of those projects whose name keeps popping up, especially in places that talk about applying the Rails viewpoint to Java. This interview with the founder was enlightening. I like being reminded that no technology is created in a vacuum. The motivations behind the technology influence its shape.

The Rife framework has several interesting ideas. The feature that stood out most to me was integrated web continuations. I had always assumed that continuations have one practical use that we developers who don't write compilers (or new program control structures) care about: backtracking. But after going over documentation for continuations in Cocoon, I understand why people have gotten excited. HTTP is a stateless series of independent requests and responses. The concept of a session is something our apps use in spite of HTTP to present a coherent, step-by-step experience to each user.

Sessions must be maintained manually without continuations. That is, the framework probably manages the session object for you, but it's up to you to figure out what to stuff inside the session object as a side effect of generating a specific HTTP response. When handling another request, the code activated by the URL must make sense out of the data in the session object at that point, and likely use it to branch in any of many different code paths. If the user tries to hit Back, something unintended may occur because he or she is accessing a previous page but going against the current session data. Business as usual, right?

The way I see it, a continuation is just a "frozen" copy of a running program that can be unfrozen at any time. For a webapp, if I'm interpreting this right, continuations can replace sessions. That is, each time the program flow returns a response (and control) back to the user, it suspends into continuation form. When the user sends the next request, the web server gets the continuation and resumes the program right where it left off, all parts of its execution intact except for the request object, which of course now represents a different request. The big payoff with continuations is that the Back button can actually reverse state, presumably by taking an earlier continuation instead. Naturally, this feature doesn't come without paying a price of greater sophistication in the code.

My work doesn't involve Rife, so integrated web continuations is not a possibility for me. Or is it? The generators (you know, the "yield" keyword) in .Net 2.0 got a lot of people thinking about continuations and coroutines. No surprise there; when Python got generators, articles like this made the same mental connection. I'm not holding my breath. My limited experience learning ASP.Net has shown that its event-driven and therefore essentially asynchronous nature is what defines it. Once you understand that friggin' page lifecycle, it's not as bad. Would it be better if there was one big page function that took a bunch of continuations for each event, and persisted between requests, rather than a bunch of small event handling methods that may or may not run on every request? Eh, maybe. If that was the case, it might make it easier to refactor code into whatever units you like rather than enforced event-handling units. On the other hand, a continuation model for GUI programming could be much trickier to learn than the event-driven callback model.