[plt-scheme] Serializable continuations?

> I come to think of them as intermediate states, where the first
> send/suspend marks a beggining of a transaction and send/finish the end.
> On transaction's end you persist the outcome one way or another, for
> example to a db, network, and in order to provide consistency you should
> be able to expire all continuations saved during the transaction's run.
>
> In cases like this the serialisation of the continuation is not really
> critical, since the overall state of the application is safe, even if
> you have a crash. Ok, you will lose your current 'transactions'.

While your analysis is correct in the abstract, it can be problematic
in practice.  Sometimes, the entire lifetime use of the application
looks like one "transaction".  This may be avoidable by restructuring
the program, but at least as "naturally" written, this is how it plays
out.  If you do restructure the program somewhat, you still end up
having some persistent state -- the canonical example of this would be
your login identity.

Now you might think, geez, I generally log in to a site only at the
very end (just before checking out books or buying tickets).  So this
doesn't really matter.  In contrast, the software I've been building
has you logged in all the time -- it makes heavy use of role-based
access control, so who you are (or what role you're fulfilling) is a
global parameter for all use of the site.

These are, of course, only a subset of all applications, but I want to
point out that the login in this case is not frivolous (like those
stupid sites that won't let you do anything interesting without
logging in).  Rather, it is essential (in that the set of
authorizations for someone not authenticated is essentially the empty
set).  Therefore, the scope of the "transaction", if you include the
login identity as part of the transaction, really does need to be as
broad as it is.

By the way, becase this sounds more abstract than I wanted it to be,
here are two such concrete applications:

http://continue.cs.brown.edu/
http://facsearch.cs.brown.edu/

Nevertheless, as I said, your analysis is fundamentally correct.  It
is in fact roughly the insight behind Jay's new "URL parameter"
mechanism, which he will preview as soon as it's ready for general
consumption.  It makes a huge difference to both performance and, more
importantly, user experience.

Shriram