Fair points, but still we would be much better of than now, when we cannot even shutdown the web-server, let alone change the code, right? What I am trying to say I guess, is that if I was running a big web service I might be ok with loosing user sessions when there is an upgrade. I definitly would not be happy about having to match user requests to specific (possibly dead) instances of the web-server or with keeping two week old continuations in main memory. -pp<div> <div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I was thinking about this, and was a bit discouraged. The serialized form of a continuation either includes the code along with the environents and store locations or it doesn't. If it does, then you're effectively stashing entire scripts, environments, and heaps in your hidden fields (or URLs!).  That's a lot of info.  And a pretty big security hole, since resuming the continuation entails basically loading a program state from an untrusted source and resuming it. If it doesn't include them, then even minor changes to the code running on the server --- adding a local variable somewhere, say --- could introduce a mismatch between the continuations stored in people's browsers and the code that would resume under their guidance. Serialized continuations are, in effect, a data format that is extremely sensitive to the exact code the server is running. This is a problem that applies to all sorts of automatic persistence tactics.  You're taking the states your program can occupy and making a file format that can represent them.  But since you're not exerting any judgement over what goes in the file and what doesn't, minor changes in your program's code result in, effectively, incompatible file formats. </blockquote></div> </div>