Re: Y Store /Closures

[Sundar Narasimhan <address@hidden>]

   >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.

I agree.. the papers I mentioned talk about two approaches --
a. encoding/keeping continations in session state (so it would appear
some of this has been solved, although from the examples I've read
thus far the continuations seem fairly simple -- so I could be wrong
about inferring practicality from that). b. there's a hint about how
monads->arrows implies that continuations can be encoded in the URL's
themselves.. I can't believe that would be practical either.. so I'd
like to know if people have explored that.

   >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.

It is.. so much that some people in RFP's ask for specific
capabilities wrt. load-balancing/scalability. I didn't get
web-switches or stateful level-4+ hardware, or why Akamai was
interesting for a while either. (Having a friend at Arrowpoint helped
mightily :).
  
A question for you though -- is the "back/clone" problem somewhat like
the "window resize" problem? (i.e. it's real, and something users
occasionally do (potentially hosing themselves), but my question is --
is this capability essential?). Do you believe that frameworks that
solve it cleanly are actually going to take "advantage" of a clean
back-button capability to be competition killers? (In practice, I
haven't worried much about the back button because in every page we
try and provide ways to "undo".. that undoes the 'last' operation, and
a page-trail, that takes users back to pre-defined spots -- users tend
to prefer that rather than hunting and poking w/ the back button to
find some place they've previously visited in my experience but I
could be wrong. The clone button I worry about even less.. we actually
"use" the clone button for spinning up auxiliary searches etc. that
the user might need to do, and actually have to "educate" our users
about it.. most of them are unaware of things like "Open in new
window" :) 
 
   Reliability and scalability, scalability and reliability, our two main 
   weapons are reliability,
   scalability, and ruthless efficiency, our THREE main weapons... :-)