[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
At 9:37 PM +0200 8/11/03, Michael Sperber wrote:
> >>>>> "Scott" == Scott McKay <firstname.lastname@example.org> writes:
>Scott> I personally don't see why a continuation, with its implicitly
>Scott> captured state, is superior to having a session object that
>Scott> explicitly captures the state.
>They are orthogonal to each other, I'd say. Continuations are about
>capturing *bindings*, not state. Session objects are usually about
>capturing state. In systems which only have the latter, session
>management usually breaks down in the face of branches in the browser
A binding is part of the state, right? I argue that, in
this domain, if you aren't explicitly capturing *all* the
state so that it can be "persisted", or if you are not
including tokens in your URLs (in links and in POSTs)
that somehow identifies the state, then you have an
incomplete design that will either:
- break in the face of load-balancing or crashed servers,
- or break in the face of the "Back" button
Our little system happened to do both things correctly,
and it was no great shakes capturing the state in objects.
To repeat myself, I still don't see how just having continuations
meets both of these goals. Yahoo Store has a sufficiently
complex user model that I would be pretty pissed if I lost
a session due to some server crash, so I'm still curious
what Paul did to address this.
Personally, I have no problems with continuations and
have even (gasp!) written interpreters and worked on
compilers that use them, but I don't find this particular
problem domain a very compelling reason for them.