Re: Continuation webapps

This is a bit RESTy. Sorry for those un-interested in this... but I
think it's on topic because it's also about continuations as devices for
managing state in webapps.


Anton van Straaten wrote:

> How do you get from REST to saying that the web "is" stateless?  All REST
> tells us is that REST servers are stateless in a certain sense.  But what
> about all the servers that don't follow the REST model?  You're also
> presumably assuming that all servers *should* follow the REST model, but
> that's debatable.  Just as with the earlier discussion about "the rest of
> the world", different approaches are appropriate in different scenarios.

It's not a crime to not use REST. But I haven't found an webapp that
couldn't be considered RESTfully.

So, yes. I think I am saying that in designing webapps I always try to
make them RESTfull. Maybe I always design the same webapp...  but I
don't think so.


> Also, in discussing state in the context of continuations vs. that of REST
,
> we should be careful that we're talking about the same thing.  And we're
> not, exactly.  REST servers often retain state that's supposed to persist
> beyond a request - database data, new & updated documents, etc.  REST call
s
> these "resources", but there's a certain amount of terminological relativi
ty
> here -- from a functional modelling point of view, resources which are upd
at
> ed by the client can be considered part of the system's state.  From that
> perspective, even REST servers are stateful, and thus the web "is" statefu
l.
> (As though it could be otherwise!)

Clearly, REST resources have state. It is Representational State
Transfer. But it's only the resources that have state. The idea is to
turn your problem into a set of HTTP interactions on resources rather
than a sequence of procedures that work on some data.


> To connect this to continuations, some of what REST calls "resources" migh
t
> quite easily be implemented as continuations.  For example, the state whic
h
> is achieved on the server at the time when a user "logs in" - all the user
's
> preferences, etc. - could be saved as a continuation, so that "logging in"
> is just a matter of resuming the appropriate continuation, at which point
> all the user's preferences are already available to the server program as
> lexical variables.  Assuming an efficient implementation of continuations
> (perhaps partial continuations, cached in memory a la memcached or JCS),
> this no more violates REST than having the user's preference information
> stored in a database.

A user login is the classic non-REST pattern: in a RESTfull webapp the
user would not "login". A user would authenticate but not login because
logins require just the sort of state you are talking about.

But I think I understand your point... but surely a continuation implies
carrying some state between requests (it describes how things continue
from request to request). And that's the problem. How is the client and
the server to refer to the continuation from request to request?

It seems to me the options are:

- page rewriting
- a cookie
- ip address detection
- authentication

The first two violate REST because they pollute resource state and the
last two are imperfect. Unless you have serialization then you will be
stuck with the server that you last spoke to.



>
> The real problem here is these kinds of things are so far outside the real
m
> of what "state of the art" tools can do, they seem superficially to violat
e
> the current "laws of the universe".   It's sort of like saying that you
> can't send messages across the world at the speed of light because no hors
e
> can ride that fast.

I don't understand what you mean.


Nic