[dev] Horde_SessionObjects

[Chuck Hagenbuch]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Horde_Cache does not work in the situation where we absolutely 100%
> need to guarantee that the data will be available.  For example, with
> the pgp/smime reload stuff, it is simply too much of a hassle to carry
> around the reload URL data from page to page.  It is much easier (and
> more secure) to store the URL in a session variable instead.
> Obviously, we could directly store this data in a temporary session
> variable, but that feels hackish at best.
>
> This could never be offloaded to Horde_Cache because, e.g. with
> memcache, there is no way to guarantee that any piece of data will
> persist.

Got it. Horde_SessionObjects was originally designed to be a queue  
that wouldn't grow beyond a certain point, so it shouldn't be the  
answer here either, really. :)

> It might be useful to refactor Horde code to call an API in order to
> interact with all session data.  Would allow us to do stuff like
> transparent compression of larger pieces of session data.

Compression is probably the best argument I've heard for having an  
abstraction layer over sessions. The other reason is to separate data  
into different buckets, so that we don't have a single, locking blob  
of data. I've been interested in doing this for a while, inspired by  
this article:

http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/

What do you think of replacing sessionobjects with something more like that?

-chuck