-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
hi ralph,
>>> 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 :)
hey, look, it's a party! :-)
>>> 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
just a thought, but since Jayson will be getting to thinking abt this in
a bit, you may want to get that version in front of him for
thought-starter / consideration ...
>>> 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().
yup. we're on the same page ...
> 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.
enuf for now :-)
>>> 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?
that's a clever idea. hadn't thought yet abt doing the date/time
comparison ...
>>> 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 ;)
fair nuf. i'll stay tuned-in!
thx again,
richard
- --
/"\
\ / ASCII Ribbon Campaign
X against HTML email, vCards
/ \ & micro$oft attachments
[GPG] OpenMacNews at gmail dot com
fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iEYEAREDAAYFAkRyDoUACgkQlffdvTZxCMatywCdEfqo+k8g33Ia89kPQv9rAOGD
bgwAn2L7BhWMSSHR20jyswNoRyzxVGJy
=Qqsu
-----END PGP SIGNATURE-----
Locked
