Chris Wrote:
yeah, but have you ever tried to have two copies of a tree open on the same data?
That problem wouldnt arise if the page containing the tree tag used a URLDataSessionManager ;-) A different Chris Wrote:
Hmmm. Please smack me if I'm wrong, but I'm not clear on how it differs much from not keeping session-related data in the token. I guess you could argue that a session token that holds application data is "more random" due to the nature of its composition, and due to that it can't be "guessed" as easily (I doubt anyone would even try). One of the purposes of the random element of the session token in the current implementation is to address this "token guessing" risk.
Agreed. With a large session-key the guessing game is hard. When storing session data in the URL it is theoretically impossible. Some people might find this appealing. (not me)
But all of these ponderings are kind of moot, because session data can be arbitrarily large (session data on the order of a megabyte will probably not be uncommon), so the data can't realistically be embedded in the token anyway.
Agreed, in-URL session data is not a universal solution. Im definitely only interested in implementing this as an *alternative* SessionManager, and I am aware of these limitations.
Its also the only sensible option that lets you bookmark your place in a session, and return to it much later (which interests me more).
I don't understand what you mean... a session token that doesn't include application data has the same property. That's essentially its reason for being around at all. (If you're concerned that the session token isn't URL-compatible, it is... the current implementation lets the session token be transferred via a query string, inlined URL elements, or as a cookie value). Parts of the token *never* expire, so you can happily bookmark something with a token value embedded (or receive and continue to resend a persistent cookie).
What about the scenario.... 1. I have a half full shopping cart (or a half opened tree tag) 2. I bookmark that half full cart. 3. I fill up the cart, but then change my mind. 4. I return to the bookmarked page - do I go to A. the half full cart from step 2, or B. the full cart from step 3? 5. I return to the bookmarked page 12 months later - do I go to C. the half full cart from step 2, or D. the full cart from step 3, or E. an empty cart, because the session cache had been purged. I guess B D and E all make sense in the context of a shopping cart (feel free to disagree; Im not too hot on shopping cart usability) I'm currently using a fremework built around in-url data to maintain the state of a sophisticated View (as in an M-V-C idiom). Options A and C are essential, since users need the ability to bookmark a view and return to it later. However most views are transient, just intermediate views on the way to the view that they want to keep. I dont have the storage on the server to indefinitely record every view that has ever been seen, however the server has no way of knowing which views have been bookmarked. The only option is to store all view state on the client, inside the bookmarked url. Being able to use a SessionManager to integrate a (rewritten) tree tag into my rich views is appealing.