[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Y Store /Closures



Sundar Narasimhan wrote:

> Hence the interest
>   in continuations.  (Correct me if I'm wrong.)
>No - I think you have it right.
>
Digression: Oh, I should have also acknowledged that the issue of 
interacting properly with the
"back" button is a very real one and that's another virtue of the 
continuation approach.
(There have been well-documented case studies of serious high-volume 
commercial
web sites that do not interact properly with the "back" button, or 
related things
such as "open in new window" and then switching between windows.  Typically
the application retains state based on the chronological sequence, 
rather than the
context as seen by the user, and so clicking "Confirm" in one window 
might really
confirm what was done in the window that the user most recently messed with
rather than the window that contains the "Confirm" button, etc.)

>Well, you asks a question I've been struggling to understand as well
>(but you say it much more clearly than I could have :) . I've been
>reading thru the Queinnec's papers, and Avi's comments (haven't had
>time to download/play w his framework yet). My guess is that they
>would respond w/ a. it's not important -- and this cps style for web
>apps is really intended for state that you don't care to "continue"
>with
>
I would not care for that answer.  Reliability is really, really 
important.  I would sure hate to
spend twenty minutes adding items to my shopping cart and then have all 
that work lost,
just because some server somewhere rebooted.

> or b. postulate that the infrastructure/language should provide a
>way of dumping / resuming computations.
>
Yes, although I was hoping for something more grounded in practicality 
than a potulation.

>The other dimension that I've been struggling to understand is how
>these facilities interact with modern load-balancers. Having the state
>maintained in a file/db allows for the machine that serves the "next"
>page hit to be a different one than the first (as j2ee or .net
>environments do).
>
That is an extremely good point, so good that I am embarrassed that I 
didn't ask it myself.
This kind of thing is one of the major architectural concerns of 
production-quality app
servers such as my employer is in the business of making. I have only 
been there four
months and am not totally versed in the art of all this yet but I 
certainly know that what
you're asking about is very important.

Reliability and scalability, scalability and reliability, our two main 
weapons are reliability,
scalability, and ruthless efficiency, our THREE main weapons... :-)