Zope session design does not match Launchpad's needs

[Gary Poster]

- the way we store our session data does not match the ZODB-inspired design (i.e., no-op __setitem__)

- the way we only want to store data and give the browser a cookie selectively (usually only for authenticated users) does not match the current design (i.e., _ensureClientId in pgsession.py)

Suggested goals for design:

- Streamline API to match what we do and expect (this should generally be a smaller API; it may also need to clarify what will trigger persistence of session data, or more precisely that modifying nested Python data structures in pre-existing session data will not be automatically stored, I believe).

- Break or expose hidden coupling between session data container and session id API.

- Consider whether we need an adapter between new design and old design (do we use standard Zope code that expects it?).

[Stuart Bishop (stub)]

I noticed this when first implementing the Launchpad PG session back end. As supporting relational and other backends was a goal when I designed the Z3 session API the previous year, it seemed like a failure in the original session API design and best fixed Z3. We can then release the PostgreSQL session code for others to make use of.