> > 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
> interested in implementing this as an *alternative* SessionManager, and I
> 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
> later.
> However most views are transient, just intermediate views on the way to
> 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
> 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...

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to