[Tickets #8023] New Horde_Session class

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/8023
------------------------------------------------------------------------------
  Ticket             | 8023
  Created By         | Michael Slusarz <slusarz at horde.org>
  Summary            | New Horde_Session class
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Enhancement
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Horde Developers, Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2009-02-23 13:51) wrote:

 From dev at lists:

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