Re: Continuation webapps

Nic Ferrier <nferrier@tapsellferrier.co.uk> wrote:

> "Anton van Straaten" <anton@appsolutions.com> writes:
> 
>
> But famously Yahoo got rid of the LISP. Maybe they had scaling
> problems?  /8->

Bear answered this one nicely.  The Yahoo case was mainly unfamiliarity with
Lisp -- think of it as programmer scaling problems.  ;)

> I don't agree. A simple URL defines a resource. I can't see that it is
> a continuation unless you wrap one round it.

I was talking about e.g. when a button on a web page is bound to a URL --
that's a continuation.  When you click on it, it determines what the program
does next.  If no parameters are involved, that's a minimal case, but if you
put the button in an HTML form with other fields, then you have a full-blown
request with state being submitted to the server -- again, a continuation
which determines the future action of the program.

> You can of course encode forward and back references in page content
> (and parameters). But this is just more state and almost always
> unnecessary.

I'm not sure what you mean by "almost always unnecessary".  Presumably, that
depends on the nature of the application.  State is essential to any
program.

You mentioned REST in another post, and I'll respond to that partly here.
The REST notion of "stateless" servers avoids retaining per-request state
beyond the lifetime of a request, but that doesn't mean you should be
attempting to avoid all state - you should always have exactly as much state
as the application needs (the EinsteinPrinciple: simple as possible, but no
simpler).  REST doesn't affect *how much* state a system needs, only how the
state flows and is shared between components.

In a REST system, state is maintained only in the part of the system that
needs it at any given time: on the client between requests (possibly in a
cache), and on the server while a request is being processed.

But this is all orthogonal to the question of how continuations are used.
If you want to store state on the client, you can do so as well with an
automatic continuation approach as without it (by automatic, I mean as
opposed to the manual continuation approach used by most webapps).  In fact,
any existing webapp could conceivably be redesigned to use continuations
automatically, without changing where state is stored.  The only difference
is that the code in the resulting converted application would be more
transparent.
 
also 
>
> Yes. But that doesn't necessarily help. What is the state? Is it an
> ongoing SQL transaction? Can it be adopted by another server that
> doesn't have the same connection to the database?
>
> No. It is very imperfect.

It doesn't suffer from any problems that the underlying technologies don't
already have.  You've pointed out that there are some operations that don't
migrate well - the solution is, don't try to migrate those operations.
Existing applications don't, and there's no reason to expect a version with
automatic continuations to.

I'll summarize, since I think we've been dancing around some of the
fundamentals:

1.  All programs, webapps or otherwise, have continuations conceptually.  In
traditional monolithic programs, continuations are mostly handled
automatically - e.g., you call a function, and it automatically returns when
it's done.  Traditional languages manage that by providing each function
with a "return continuation" consisting of a return address and the saved
state of the calling function (e.g. the stack).

2.  In traditional webapps, continuations are managed explicitly - as I
mentioned, state is kept in places like HTML forms and server-side session
objects, and HTTP requests and responses are used to transfer control.  In
effect, these programs are written in explicit CPS.  There are various
papers about this, e.g. (to pick one whose title I remembered offhand)
http://citeseer.ist.psu.edu/626882.html .

3.  Languages that support capturing the current continuation and treating
it as a first-class object raise the possibility of un-CPS-ifying webapps,
allowing them to be written in a more natural style.  This doesn't
necessarily imply that the nature of state handling in the program needs to
change.  However, in practice, you'd need to make sure that your
continuation technology can do what you need it to do - for example, if you
want to keep state on the client between requests, you'd need to be able to
migrate continuations to the client.  Not all Scheme implementations can do
this, but some can.

Anton