Stut wrote: > Richard Heyes wrote: >>> You use a session variable for that? >> >> Why not? > > Because it's not user data, it's server data. > >>> That's entirely the wrong place to >>> store something like which database API is installed. >> >> Not really. You could even wrap a function called (for example) >> Feature() around it. > > Yeah, really. Sessions are for user data. If it's the same for all > users then it doesn't belong in the session, it belongs in a server-wide > cache. > >>> It should a class >>> variable or global configuration variable. Heck, I'd say it's more >>> appropriate to do extension_loaded( 'mysqli' ) on every call than to use >>> a session variable. >> >> Why? It's very unlikely to be changing between calls. And even if it >> does, it's once in a blue moon. Granted though, I can't see it being a >> particularly intensive function call, so I can't see the harm in >> calling it on every invocation. > > AFAIK a call to extension_loaded is pretty cheap, but if you really feel > the need to cache it between requests the best place to store it would > be in a file on the server. However, I'd expect a stat on that file will > be more expensive than calling extension_loaded. the on disk file could be [re]generated automatically when the server is started up by the application and dumped onto tmpfs or even not stored as a file at all but directly in memory using apc or something similar either way I agree it's a server wide setting that is garanteed not change as long as the webserver is not restarted - atleast I can't see an extension becoming available 'just like that' ... going on the basis that dl() should be illegal ;-) - actually it is not available if your using a threaded webserver (who does?) and as of php6 not webserver SAPI implements dl() not to mention safe_mode which also disables it. > > -Stut > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
