>>> $_PERSISTENT could store data key'd to the script that stored it. >>> $_PERSISTENT_GLOBAL (probably a better name can be found) could just >>> store data accessable to any script under a certain document root. >>> You definitly do not want to share persistent data across document >>> roots (ie virtual servers, etc.). >> >> Using docroot sounds good idea. I'll think about design and >> post new RFC next week. >> > > Here's another idea that I've floated the last couple weeks (this would > be especially good in the SRM and msession extensions), how about a > method to cache values? This is very similar to the "application > variables", except that there would be a limit to how much was stored, > and if that limit was reached, the most infrequently used data would > be discarded. This sounds interesting, but makes the implementation of msession and SRM practically impossible. A global system-wide cache would be a nightmare. Trust me, I don't want to work on those cache coherency issues. The locking mechanim would require a lot of network I/O, deadlock contention, and lock owner crash detection. It would take for ever to get right, and you would be endlessly fixing borderline bugs. > > Right now I've got some lookups I have to do fairly often for country, > state/province, city of users. There are over 2 million cities in my > database, but the vast majority of them aren't used. I would like to > be able to store the most frequently used data in a persistent manner, > but there's really not the option of storing everything. So if it > wasn't in the persistent variable, I would look it up in the database, > and then put it into the persistent variable. The caching mechanism > would then delete a value if necessary, e.g. the least recently used. This sort of thing can be quite easy for a specific application. Coming up with a generally useful API can be daunting.
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
