Mike Orr <[EMAIL PROTECTED]> 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 appropriately. >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 either. ;-) 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. Regards, Paul -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-discuss
