Re: Session management module - thoughts

On May 29, Zeev Suraski wrote: > I've glanced through your mail and the various mail traffic it resulted > in. I must say I generally disagree. As a rule of the thumb, I think our > implementation should be as simple to use as possible, even at the price > of being unconfigurable. If you want configurability, by all means, > switch to phplib and get all the configurability you can possibly want. Just to be clear, I think the ideas that Sascha and I were kicking around would be entirely optional (and most of it really is trivial once your proposal is in place). The simple session_start/register/end mechanism is also what I would see most people using. Please be careful about disagreeing with something you've only glanced at. > The only configurability I think we must have is pointing the server at > where to save its session information, and at least in the initial phase, > what I mean is a simple path pointer in the php.ini file. After we get > that working, some might be interested in supporting storage devices other > than files, but I really don't think that should bother the average user, > and bare in mind that's the target we're addressing. A path pointer in the php.ini file isn't good enough, as some people (and I'm thinking of those using a PHP installation that is provider- installed) don't have access to that form of configuration, so we need to expose this at least as a function to precede the session_being call. > If you want to build upon this API with some extra functions, I won't > object, even though I don't think it's worth it - complex stuff can always > be implemented at the PHP level, in PHP 4.0 more than ever before it's not > that much of an overhead. Since more complex requirements will usually go > hand in hand with more capable webmasters, the fear of them not being able > to install and configure phplib wears out. All the extra stuff we've talked about has really been providing the hooks to do this building of more complex functionality at the PHP level. > Note that writing this simple API raises a couple of problems, and I think > it would be best for us to concentrate on them instead of dividing our > efforts into a feature-full API that will never be properly implemented, > at least not in the near future. The problem it raises as I see them: > > * Platform independent file locking > * Cleanup of old sessions > > Unless somebody seriously objects to what I say here, I think we should > begin to discuss how to go about doing that. We already have platform-independent file locking in the form of our flock() function, I believe. The dbm support also does some sort of locking, if I recall correctly. I'm not sure how to handle cleanup of old sessions. Unfortunately, that seems like it would require something that is definitely not idiot-proof (requiring people to stick a cron job in their crontab), or something ugly (have PHP do a sweep of the session data storage every time session data is accessed). Anyone know how ASP deals with it? Jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net