Link is to a message from Jay McCarthy, discussing why continuations are a nice way to solve session management.
[Comment removed by author]
I ran production Seaside on Gemstone/S. It was the best development experience I’ve ever had for web apps that need to maintain state between page requests. That part was all Seaside. Gemstone/S is a thing of beauty unto itself.
Very interesting. I see Seaside also defaults to putting a continuation identifier in the query string, which I don’t like that much. (Racket does this too, but I think you can force it to use a header or a hidden form instead).
In Seaside, how do they handle the problem of using a load-balancer to scale a service? Do they have a way to fully serialize the continuations? Racket has an approach called Stateless Servlets which runs an automated transformation on the code to convert it into a form that is serializable, then supports either saving it to some shared storage or just sending the whole thing to the client and getting it back with the next request.
Also, from an earlier message in the linked thread, here’s the journal paper introducing the Racket web server, with a lot more discussion and motivation: http://www.ccs.neu.edu/racket/pubs/hosc07-sk-mf.pdf
Managing state is the bane of every (web) developer’s existence. While HTTP being stateless can be nice at times, it means that it is entirely the responsibility of the application programmer to handle state. Having facilities at the server level to handle that cleanly is an intriguing solution.
The two main drawbacks of Racket’s send/suspend are the ugly, long URLs it generates and the fact that they become invalid as soon as the module changes. With the traditional stack you normally have stable URLs with mostly stable interfaces.