On Friday 01 February 2002 06:29 pm, Ovidiu Predescu wrote:
> Hi Judson,
>
> On Fri, 1 Feb 2002 12:53:32 -0600, Judson Lester <[EMAIL PROTECTED]> wrote:
> > > > Would a session not be the appropriate place to store continuations
> > > > and associated data? The URL strikes me as a really bad idea, as it
> > > > should be a logic-level address (ie foo.com/add) rather than an
> > > > implementation level (foo.com/add/4ff.) Under what circumstances
> > > > might you wish not to resort to session?
> > >
> > > This is a good question.
> > >
> > > If you look at the concept of session in the servlet environment, you
> > > realize it's only a way to save state across HTTP requests. But with
> > > continuations, you no longer need this! The continuation saves in it
> > > the complete stack frame of calls, including local variables. When a
> > > continuation is resurrected, it will contain the values for all the
> > > local variables you declare.
> > >
> > > What you're referring to is probably not session, but cookies. The
> > > problem is you cannot use cookies to encode the continuation's URL, as
> > > this would prevent the user from hitting the back button. This happens
> > > because the cookie is set globally, for the whole domain. Hitting the
> > > back button will not change the cookie's value to point to the right
> > > page.
> > >
> > > So clearly you need a way to encode the continuation's URL in the page
> > > itself, rather than assign it to a cookie.
> >
> > I personally agree with Allan, that trying to encode a user in his URL is
> > problematic. However, I don't see why it would be impossible to
> > establish a cookie backed session, and then store the coninuation tree in
> > the session, with a map of URLs to continuations. This gives you the
> > session-hijacking protection established by Servlet session scopes, but
> > allows you to also get back-button-to-previous-continuation feature that
> > Ovidiu has slowly brought me to understand completely.
>
> Ah, I see your point. Allan and you propose a two level indirection
> scheme to obtain the continuation. The first level is keyed by the
> cookie, and points to the session object. The second level is keyed by
> the URL and points to the continuation.
>
> This would probably work fine if an URL has exactly one continuation
> associated. However I'm afraid this may not be the case, an
> application may use the same URL multiple times to do different
> tasks.
>
> Suppose we have this case:
>
> History stack
> /a
> /b
> /c
> /a
> /d
> => /a
>
I think you're breaking the continuation addressing in the wrong place.
What I'm thinking (and perhaps so is Allan) is that any one continuation is
essentially a specific page served. So if I go to a website, browse around a
little, and follow a link back to the homepage, then the two different home
page visits are different continuations, (although if a click back, it'd be
the same continuation). N'ce pas? Further if I visit the homepage at the
same instant that you do, that's two different continuations.
I think what I'm trying to make sure that the difference between Judson's
continuations and Ovidiu's continuations is that I have a different cookie
than you do, but the difference between my coninuations might be encoded in
the URL.
History stack
/a-3
/b-1
/c-1
/a-2
/d-1
/a-1
This would mean that I couldn't look over your shoulder, write down your URL,
walk across the lab and hijack your session. Better still would be if the
URL weren't the encoding system, because there also the issue of people
bookmarking a continuation, or trying to screw the system up by writing their
own URLs.
Can you see this point of view? I could also see how this might be
super-trivial and something you'd ignored. But rewriting URLs to mark
session has significant issues which continuations inherit.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
