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.
Hmmm... I think I see what you're getting at. It may be outside the scope of session- tracking altogether, although you could probably build something like this on top of the session tracking machinery. It's not really session-tracking, it's... snapshot-tracking. You're not really required to keep any notion of a "session" to do what you want to do, it's just a disconnected series of states that are storable on the client side.
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)
Well, in traditional session-tracking, the answers are most likely B and E. If we could get even to there, I'd be happy... :-)
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.
I'd encourage you to put more thought in to how something like your snapshot-tracking could be aided by the session-tracking components outlined in the wiki...