Tickets :: Comment on [#8023] New Horde

* Your Email Address
* Spam protection	Enter the letters below: . ,.__ .___ ..__. \./ [ __[__ \|\| \| \| [_./\| \__\|\|__\|
Comment	> From dev@lists: > > > > Quoting Michael M Slusarz <slusarz@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 > >
Attachment
Watch this ticket

Saved Queries