[Zope-dev] Re: CoreSessionTracking proposal

[Chris McDonough]

>
> > 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...