[Zope] Question on: How-To: When Cookies won't do it

[Johan Carlsson]

> 
> I don't really know, and don't have the time right now to figure this out 
> properly. Jim Fulton will be a better person to answer this. Also, you 
> could look through the ZODB UML Model:
> 
>    http://www.zope.org/Documentation/Developer/Models/ZODB
> 
> 
> >- Why can't the session object rely on the ZODB memory cache.
> >   They are (for the most) fast deployed objects.
> >   Maybe even use _v_ objects (which would be automatically destroyed).
>
> There is at the moment no API for using the ZODB memory cache outside the 
> ZODB code itself, afaik.
> >- How does transactions slow down the process, and how are
> >   transactions connected to storage (in this situation)?
> Not so much slow down as cause undesirable side effects, like storing a 
> complete change history of the changed object. See the ZODB UML for more 
> information.

Aha, I see! Great point there.

 
> There are plans to allow use of multiple Storage types within one Zope 
> object hierarchy. Also, there are Storage available now, that do not 
> support Undo (discard old versions). When multiple storages are 
> supported, you could use a in-memory storage without undo for session data.

And the in-memory storage would have it's own ZEO-server for distributing
and load-balancing session data, I suppose. 
That explains the need for the in-memory storage option.

(Is this what DC have in mind, DC folks?)

It would be great to have a session API pretty soon, that
could be used to create session aware prototypes that
could migrate to ZEO and Multiple Storage/In-Memory Session 
solutions in the future. The session implementation could be 
something less complicated for a prototype.
Or is that to much work and to much unknown facts about
future implementations?


//johan