Re: Session management module - thoughts

On Fri, 28 May 1999, Jim Winstead wrote: > 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. I saw the session start function that required at least one argument and the session variable registration that required a session handle argument, and didn't like what I saw. I'm not on some power trip on who prorposed what, I really think it's in our best interest to implement something simple because (a) you rarely need something complex, if you do, you're probably clueful enough to use phplib (b) it's quicker to implement simple APIs. > > 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. In fact, I don't think that users should have anything to do with this. If I'm an ISP, why would my users have to specify where they save their session information? I do think it's the ISPs job to configure it. > 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. If flock() works properly under all of our major platforms, I guess we can use it. > 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? While I don't know how ASP deals with it, I can think of a vague approach towards a solution. We can probably spawn a thread (under Win32) or a process (under UNIX) that'll simply clean up old sessions, while sleeping most of the time. We can kill this thread/process at the server shutdown. Zeev -- ----------------------------------------------------- Zeev Suraski <zeev@zend.com> For a PGP public key, finger bourbon@netvision.net.il -- 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