Randall Randall  <randall@randallsquared.com> wrote:
+---------------
| Ralph Richard Cook wrote:
| > change a parameter if he needs to. Before, doing that kind of test
| > would mean leaving that page, and you'd need a continuation or cookie
| > to keep the parameters between pages.
| 
| "continuation or cookie"?  Perhaps you meant "need a cookie, form
| variable or path information to store a pointer to a continuation"?
+---------------

Cookies aren't useful in keeping track of multiple browser windows,
since they're limited to only one per server per key, and there's
no easy way to tie browser windows to keys.

+---------------
| Frankly, given macros and the fact that state will be stored on
| the server, I don't understand the point of using CPS for web
| applications...
+---------------

You really don't need CPS *per se*, but constructing your web app
in CPS *style* enormously simplifies the handling of multiple
simultaneous sessions from the same client host [note that *all*
the hosts behind a NAT gateway appear to the server to be a single
"host"!], not to mention multiple windows from a single browser.
[See multiple papers on the "Web Continuation" approach by Queinnec's
and Felleisen's teams.]

As an end-user, I really get frustrated when services offered on
the Web get this wrong. When I'm browsing some vendor's site, I
*often* click a link with middle-mouse to get a parallel exploration
started, so I can look at alternatives before committing myself,
and am enormously irritated when something I do in the new window
messes up the state in the old one!

[Analogy: When you're browsing a physical bookstore, you don't have
to commit to a decision on whether you're going to buy the first book
you looked at before you can go leaf through a different one. So why
should buying on-line be different?]

As a web implementor, I also find it amazing that other implementors
don't bother to get it right, since it's really not all that hard --
just use a small amount of "hidden form data" [compressed/encrypted/
timestamped/nonced/authenticated to whatever extent the application
absolutely requires (but usually simple cleartext is fine)] to encode
the state or a representation of the server-side state into the each
HTML form. [And forget cookies altogether.]  Problem solved. Multiple
windows (including "forks" of a session created by using a middle-click)
now work correctly, and the "Back" button now works reliably in the
intuitively-correct way in each one.

At that point the only problem remaining is the proper strategy to
"garbage collect" the server-side state [if any], but that's a problem
one always has when there is *any* server-side state (including a
database, by the way!) -- it's not unique to the "web continuation"
approach. In fact, by keeping most of the volatile state of the
user interaction history in the browser window, the CPS-like style
minimizes the amount of the server-side state to be managed!


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607