Re: Session management module - thoughts

On Fri, 28 May 1999, Jim Winstead wrote: > On May 29, Zeev Suraski wrote: > > 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. > > We're just kicking around ideas to make sure we don't paint ourselves > into a corner with a too-simple API. It would be a shame if in six > months the advice given to people on the PHP mailing list was "well, > to do that you have to use this third-party stuff instead of the > built-in support, and they don't look at all like each other" > instead of "well, just do this in addition to the built-in support, > and it works great!" > > I agree that having session_begin() return an identifier and > requiring it in session_register(), et al, is a bad idea. So make > it return one and let it be optional in session_register, much > like it is for connection ids in mysql_*(). This seems like a > very cheap addition to the API for the flexibility it offers. Granted, if we were to do it this would be the way to do it. That's what I thought, but I simply couldn't find any situation where you might want to have more than one concurrent session. > (Here's a problem I'm trying to avoid: if the session support isn't > flexible enough to satisfy as many users as possible, it will get > very little support from PHP "power-users" and other developers, > and will end up being more of a burden than a benefit.) That's a general rule of the thumb - but think about it - will that sort of sessions be suitable for your needs? It fits mine, and I consider myself a power user (I hardly write web projects nowadays, but I've had the honor of writing some and seeing many others; can't think of any single project that wouldn't work with this API). I'm not against adding hooks for future use, as long as people can still use the KISS version without any added overhead. > And they won't. We should provide the hook so that people can do > the right thing if their ISP doesn't. Should we require everyone to > use it? No. Would it be great if every ISP configured it so it > worked for users out of the box? Yes. I really think that's something that ISPs should either do or not support sessions. Having users starting to move files around your file system isn't a good idea anyway, from the ISP's point of view. I'd imagine sessions as a whole will have to be turned on explicitly on the server, since it'll be saving files with the server uid, so some good will on the ISP's side will be required anyway. That said, PHP 4.0's INI mechanism is so much superior to PHP 3.0's that this isn't even a problem. Add php.ini support for that path, and you can override it with .htaccess or registry or even using runtime functions without having to write a single line of code (unless, of course, we decide that we don't want it to be overrideable, and flag it as such). > > > 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. > > That's also not going to be acceptable for some ISPs. Many strictly > prohibit their users from running their own daemons. I think we > need to provide the fallback of doing the cleanup on a per-request > basis (perhaps regulated by some element of randomness as PHPLIB's > apparently is). Uhm, it won't be the user running the daemon. It'll be the ISP, as a part of the PHP installation. If you enable sessions support on your server, you spawn a session data garbage collector for your server - it goes hand in hand. Doing it on a per request basis is a performance nightmare, both theoretically and in practice - I/O will kill you. 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