Richard wrote:
I'm marking this one to look at when I'm into Zend_Session in a few days...
Awesome, I am looking forward to comments from Zend on this :)
reading through the proposal & source, and php docs on native
session/gc, i've got a handle on its use for "just" session data.
i'm interested in "hooking" into it ... kinda fuzzy, so let me try a
scenario/example ...
Considering Zend has not looked at the proposed api in proposal v3 yet,
I hesitate on releasing my new version of Zend_Session that has the
plugin interface implemented (sort-of). The idea behind the data
plugins is that, once a new plugin is registered, it will have a
namespace in _SESSION it can manage via: set, get, has and remove
functionality. It will also be able to register custom startup() and
destroy() functions. Much like Zend_Front_Controller's plugin architecture
revisiting an earlier question, i'm thinking -- again -- about its use
in gc'ing tangible resources that are relevant only to & during a given
session.
e.g., dymanic images created for a user's particular session.
Personally, I would that since the domain logic of creating these images
exists in some class, that class should also manage the
destruction/cleanup of the things it creates.. I agree that there
should be some static methods, perhaps in the Zend_Session_Tools class,
that will do things like Zend_SEssion_Tools::sessionStillExists() or
Zend_Session_Tools::getAllSessionIds().. But that is not functionality
that exists in the ext/session extension since ext/session is session
centric and not sessions centric, if that makes sense.
sooooo, i *could* add a cleanup routine to the Controller -- either
destructor or constructor would do, i think -- , determine a list of
active session IDs @ the server level, scan/parse the image/tmp dir, and
delete dirs unmatched against an active session.
apart from the fact that that feels 'clunky' to me, i immediately wonder
if i can't leverage Zend_Session's access to session ids, session data &
gc routines, and extend to add this "real file" management.
Your controller might be the place to implement garbage collection. In
a similar style to session_gc functionality:
// garbage collection - similar to php's gc
if ($this->_gc_probability > 0)
{
if (mt_rand(0, $this->_gc_divisor) < $this->_gc_probability)
$this->_garbageCollection();
}
divisor 1 and probability 100
means a 1% chance of running.
then in the gc function, just check to see if the files are older than
the same amount of time as your session, perhaps 2 weeks?
QUESTION: is Zend_Session-to-be the right place to be dealing with this?
there's gotta (should?) be a smarter/more convenient way to manage
transient files ...
jury still out on this one, technically, the api for Zend_Session needs
to be nailed down first, then one can answer this question correctly ;)
-ralph
|
