The Scheme community is rather big on shaking their finger at web developers because many web applications don't manage state properly. Hit the back button when the developer least expects it, and the results are unpredictable and undefined. Lord help you if you start opening links in other browser windows mid-transaction. Logically, your state should continue based on the contents of the page currently loaded -- whether it's a few pages from your previous state, or an unexplored branch of your transaction.
The solution? Use continutations to manage state for you transparently! Send a small token on what the next state should be from any possible branch point, and the app should always behave properly, whether you behave linearly, use the back button or open new browser windows. Furthermore, app development should be easier, because the process mimics simple interactive console programming (the stuff with print, <STDIN> and the like).
Let's assume for the sake of argument that continuation-based development frameworks are all properly REST-compliant. That is, the continuation is always available as a GET parameter.
So, what happens when I send one of these URLs to a group of friends? On the one hand, the one state that I sent to 10 people can take 11 possible simulatneous branches - one for each possessor of the start state.
On the other hand, what happens when that URL is from an ecommerce site? What happens when the continuation remembers my account ID and my current shopping basket? What happens to the 10 new states -- do people shop with my preferences, place items in my shopping basket, and check out the items I've put there? Do I check out the items they've put there? [*]
Hm. Smells like continuations are a silver bullet. And there is no such thing as a silver bullet in this industry...
[*] Yes, continuation proponents recognize that you should be able to mark a shopping cart or similar transaction as "expired" when someone has taken it through the checkout. That problem is orthogonal to capturing too much state in the continuation. The core issue here is that continuations don't solve everything with mismanaged state in web applications, and there are ways to properly manage and mismanage state both with and without continuations.
One thing that should absolutely not be captured in the continuation is authentication. It's all well and good for the continuation to represent the complete state of the program as long as there's absolutely no way to authenticate without knowledge of the user's private key (or password, or whatever). Any attempt to restart a continuation should authenticate first. Assuming the authentication uses cookies or passwords stored in the browser each session, and the communication link is encrypted, this reauthentication should be seamless to the user.
The problem is akin to, but more complex than, the social security number problem, where knowledge of a person's identification number is irresponsibly assumed to constitute proof of identity.
Another problem I see with this continations-solve-all pancea is that your server can never destroy any of its continuations. For a local language with continuations, you know where all the references to a continuation are, and so after the last has gone out of scope, you can delete the continuation. (Not necessarily immediately after, given that you're probably using a garbage collector, but the ability to tidy up is there)
If you give out references to continuations to the remote web browser, how do you decide when they don't exist any more? Particularly if that web browser's user is allowed to pass them on to her/his friends?
Re:Garbage collection
ziggy on 2003-12-31T16:23:17
Actually, it can and it does, except in the trivial examples (i.e., the kinds of stuff the papers write about).Another problem I see with this continations-solve-all pancea is that your server can never destroy any of its continuations.From the stuff I've read about continuations on the web, the technique is to take a continuation and store it in a table. The browser gets a key into that table, which is used to invoke the continuation. So all of the references to the continuation are still local.For a local language with continuations, you know where all the references to a continuation are, and so after the last has gone out of scope, you can delete the continuation.Same as usual. You put a timeout on them and have a thread/process reap expired continuations. The reference is lost, and the continuation (and its captured state) are subject to GC.If you give out references to continuations to the remote web browser, how do you decide when they don't exist any more?
