Gertjan we are straying ogg licensing a bit bit to comment on your comments....
a) reattaching to the logged on users stuff breaks down if you want to allow the user to (legitimately) open another browser window - this would need to be a brand new session b) storing data in-page was my preferred concept a whil ago but this breaks down - or the complexity gets much to large simple example suppose you are in a shopping cart type app you need to navgate all over the place but still keep track of what was ordered - I believe that it is unrealistic to keep this in page in-page was what i did before my current trchnology - and yes there things that you have to pay attantion to (back button and Ctrl n) c) On long time outs - this is an intranet app - the user does not want to be logging on every 10 minutes, typically they open the browser in the morning, and keep swopping back to it - do some work, answer a telepone query - a la old style terminal app d) agree with you re the session app - that's why I use my proxy classes - although this is implementation rather than signifigant - i am keeping a sens of state server side Peter On Fri, 20 Aug 2004 21:03:14 +0200, Gertjan Klein <[EMAIL PROTECTED]> wrote: >Peter Cooper wrote: > >>a) the data stored in the session temp store (my proxy classes) may be >>out of date (stale) or otherwise invalid cos another user/session has >>changed the persistent data > >How is this different from the situation where the session timeout is >eight hours (and one user goes out to lunch while another is changing >data behind their back)? Just to clarify, the "fix" I tried to >describe should behave *exactly* the same, it is *only* the license >that should timeout sooner. > >>b) in complex series of pages making up a single transaction you have >>to store all pages and jump back in the middle > >Same question, I guess. > >>c) How do you cope with the user opening a new session window >>deliberatly - they would not want to reconnect to the existing session > >Why not? IMHO, the session object should *not* be used for any >significant data, only user information. The data regarding >transactions etc. should always be stored in the HTML pages (this what >I believe is called "page state"). > >>all in all it's much safer in a data intensive app to re-start >>everything otherwise it's simply too hairy > >Perhaps, but that would be the same for an app with a long session >timeout. Again, I only tried to describe a way to handle the licensing >problems we discussed, not how to handle other aspects of session >timeout and/or session data persistence. > >Gertjan.
