Peter Cooper wrote: >we are straying ogg licensing a bit bit to comment on your >comments....
Alright, let's forget about licensing for a while (well, I'll try) and talk CSP apps in general then ;) >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 I don't mind users opening new sessions, or having multiple sessions open at the same time -- I see no need for it, but that's what they do and we have to accommodate for it. But although my main point was reattaching to the user's license rather than the session, I'm not convinced the latter is a bad thing (see next point). >b) storing data in-page was my preferred concept a whil ago >but this breaks down - or the complexity gets much to large The biggest part of the complexity can be automated away, as I'm sure you're aware. If you keep stuff in %session.Data, what's to keep you from automatically storing it in a hidden form variable, and automatically restoring it on form submission? You can even automatically keep a state history in a global somewhere, so e.g. use of the back button doesn't erase placed orders. (This is leaving strict usage of the page state principle somewhat, though -- but page state has it's usage, even though it's not the only tool available.) >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 Up to a point. Once an order has been entered, it should probably be persisted (with a "pending" flag) until, say, payment details have been entered. Done this way, it makes no difference if the user goes back to the item selection page through the back button or an "add an item" link you placed. It may be a matter of taste, but if I place an order (but don't finalize it by paying), and close (crash?) my browser and open a new session, I'd like my pending orders to be there. As a programmer, I'd also like to recognize I'm dealing with the same user, and attach to the same license (without needing an extra license just to deal with this situation). Do you see other problems I didn't address? >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) In-page state is useful for stuff you'd normally place in %session, and deals with the problems of keeping session state server-side. It is not the answer to all web-app issues, of course. (I would never store orders placed-so-far in %session, though.) >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 But they don't have to (login every 10 minutes) -- unless you use hyperevents. If you do, the practical problem of not being able to automatically re-allocate a license should probably be addressed by filing a bug report with ISC, as it *is* possible (with some caveats, discussed before) when, say, reloading the page. IMHO, the coupling between session and license ISC created is to rigid, and can be made much more flexible -- without doing any damage to their license policy. I'm not convinced supporting web (as opposed to intranet) CSP apps by giving the programmer more control over which session belongs to which license has high priority with ISC, though. >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 As I said, state in any significant app probably needs both client-size and server-side components. I know you've described your proxy classes to me before, but for the sake of others (and my poor overloaded memory ;), could you describe what issues they address? (Looking back at what I wrote, it seems I couldn't resist bringing the L-word back into the discussion... ;) Gertjan. -- Gertjan Klein
