Mike Orr <iron@...> wrote:
[Cookieless sessions and the need for session identifiers]
>Not sure what you mean here, but one issue I forgot to mention is that
>if you're going to do cookieless sessions, you have to put the session ID
>into *every internal link* on a page. Thus, you can't just use static
>links, you have to make every one of them a plug-in variable and call the
>method that sessionizes the URI. This can be quite an inconvenience.
Of course there are always going to be issues like this with cookieless session
management, but I suppose that I should should admit that my personal
experiments (as previously announced) are designed to attempt to deal with the
whole business of sessions without necessarily implementing them using
the "cookie with identifier, data stored on server" approach. When I say
sessions, I reiterate the distinction between sessions stating "this person is
different but anonymous" and sessions stating "this is person X", noting that
the former can be implicit in the communications taking place. In this message,
I am referring to the former.
One of the reasons I brought up time-expired sessions, and the pain that they
can bring, is that it must surely come about from the restrictions or perceived
restrictions of this approach. Perhaps people deploying Web applications don't
want to have to store lots of session data on their disks for a potentially
huge number of casual, anonymous users.
>It sounds like your application may be different than general session
>management. You just want to maintain the state between the form pages,
>rather than across the entire site? Then automatic hidden fields on forms
>may work for you. But if you want to allow the user to go to a non-form
>page and back, while still maintaining the form values, you'd need a
>traditional session object. Otherwise you'd force the entire site to
>build every page in the forms framework.
Indeed, I mentioned that hidden fields are employed to retain the state and
that this does the job just fine. Of course, the restrictions are clear: any
link not providing the information contained within the form is going to result
in a loss of state, but then a framework which promotes this kind of state
management could (and should) provide the means to generate the links
>Expiring session data happens on the server, so you have no control over it.
>I was talking about lengthening the timeout on your sites, so that your
>visitors wouldn't get caught in that trap.
I'm not so interested in imposing bizarre timeouts on any sites any time soon;
indeed, I'm not going to be deploying any sites of my own any time soon
Seriously, though, I don't believe that Web application or framework designers
think too hard about these issues. Why should I, with my multitasking PC and
potentially disruptive office environment, which may demand my attention at
numerous unforeseen moments, have to sit down and reserve n minutes of
completely uninterrupted time to perform some task in a Web application, just
because of an artifact of the implementation mechanism? It seems so
unjustified, yet some attempts to book airline tickets and participate in other
online transactions seem to be curtailed by such demands.
Get your firstname@... email for FREE at http://Nameplanet.com/?su