Excellent question.

Right now, in my beta-ish stage, I am saving all continuations. Yup, allofem. So when they hit 'back' they go back in time to a previous state and can continue from there. Or they can split into two browsers and each get their own branch, etc.

In the future I will add some management stuff for the application to access. The idea is to have a call which says "ok, now that I'm done processing their credit card, delete all the previous states so they can't go back and do it again on accident".

This unfortunately doesn't solve the stickiness problem of (say) a shopping cart: you don't have a way to back-propagate adding an item to a cart to the old continuations. You could can have them just keep pointers to state, not the state itself, but then you end up needing to maintain that too, which is something continuations set out to avoid.

Don't get me wrong, I'd love for this stuff to work magically well and let us be rid of the pain that is application programming over a stateless protocol. Maybe continuations have their place in the infrastructure of the Non Sucking Web. But they're not all that's required.

You are absolutely right -- and I would end up putting the shopping cart data into a DB or similar. I think in that case it might even be better because they could log out, go away, and a long time later come back to the same shopping cart, without me having to save their continuations the whole time.

Another idea is to have a per-session store for this sort of thing. Right now I have, for a given session, a set of continuations for all the states they've been in. So if we want we could bring back a general session storage area for this sort of cross-continuation storage.

I personally prefer the DB storage, but this would work too. Either way We still get the benefits of the control-flow using the continuations.