[Zope-dev] Re: CoreSessionTracking proposal

[Toby Dickenson]

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.