[plt-scheme] Continuations vs REST

Hi Noel,

Thanks for the writeup.  It was useful to learn of Nagare.

That said, I don't really agree with your article.  I think it sets up
a false dichotomy and thus undersells continuations.

-----

The heart of the issue is one of naming and identity.

Suppose we had an infinite amount of memory in a server that runs for
infinitely long (never crashes).  On this very convenient server, we
build an infinitely large table, each of whose entries has a unique
name (eg, 1, 2, 3, ...).

It's very easy to implement a RESTful system in this world, as you
well know.  But, you argue, there are two problems: load, and scope.

-----

I want to tackle scope first, even with your own example: convenient
login.  This means, you're saying, if I visit

  mail.google.com

and authenticate, and then get a cookie, then visit

  calendar.google.com

I will already be authenticated, so I get my calendar -- but not in
the other order.  But that means

  calendar.google.com

is not a very RESTful URL: the same URL seems to produce different
answers at different times!

So you seem to really have in mind some notion of RESTfulness but with
a little state on the side.  And if that is so, then the state can be
stored anywhere so long as it's accessible.  It may be that cookies
are the most pragmatic place to store them, but they are not the only
principled place (per our almost-equivalence between the store and the
cookies, first presented in our ASE 2001 paper).  To use your own
words, the server's store (or database) is also "per browser".  Where
to put it (cookie or server database) is a matter of space-time
trade-offs, security, etc.

-----

Now for load.  Yes, it's rather hard to find this server with infinite
memory and uptime (I found a few on eBay, but the dealers had low
scores so I wasn't sure I could trust them).  Let's go back to our
implementation: we have a table, the table indices store the
continuation, and the client is sent the name of the continuation in
the table (name = "1", "2", "3", ...).

But of course that isn't the only representation possible.  The table
could instead be associative, and the names could be terms like

  (lambda (x) (+ 5 x))

or, for those of a more traditional associative array mindset,

  "(lambda (x) (+ 5 x))"

So now we have a(n infinite) table indexed by such entries, and the
client is still being sent the name of the continuation in the table
(so the name of the

  (lambda (x) (+ 5 x))

entry might be

  "(lambda (x) (+ 5 x))"

when broadcast).

This now brings up the obvious question: do we need the table?  No, we
don't.  But if we don't need the table, do we need the uptime?  No, we
don't need that either.  And if we get rid of the infinite table and
infinite uptime, we're left with Apache on a machine I can buy from an
eBay dealer who *does* have a top rating.

-----

Obviously, I have simplified some things in this account.  But I felt
it is important to present the account anyway lest people assume what
I am calling a false dichotomy.  As I'm sure you know, Jay has long
been bothered by this question, and has made real progress on the
problem of reconciling REST with "real" continuation URLs, and this
time with massive performance numbers to boot.

Shriram