Re: Session management module - thoughts

On Fri, 28 May 1999, Rasmus Lerdorf wrote: > > Looking at PHP 4.0, one of the only major issues in which it falls behind > > ASP is internal session management. > > I know Rasmus always said this stuff belongs in user space, but basically, > > my opinion is that anything that more than a few people use, is better off > > being written in native C. > > It's one of those marketing checkmark features that I do agree are > important. Basically if you are writing a database-driven site, tossing > in a cookie and storing user data alongside your other data is pretty > simple. But for Joe User out there, having a simple session mechanism > would be a good idea. agree;-) > > > What I have in mind is a KISS approach to sessions, through a built-in PHP > > module. For information storage - use files. Implement functions that > > start a session, that add variables to a session, and possibly that end a > > session. At request_shutdown, simply store all variables that were > > registered as session varaibles in a file, named after a unique key that's > > generated by the session starter, and passed along through cookies (I > > think it'll be fair to rely on cookies, and point people that don't trust > > cookies to phplib's session support). > > ASP's session support is cookies-only as far as I know so we can just say > that PHP has session support that is on-par with ASP. > > > In essence, assuming we have working serialize functions, all we have to > > implement is file locking support and something that will clean up old > > sessions, neither of which are beyond us. > > Why do we need to lock? Assuming each session gets its own unique file > there should theoretically never be more than one process reading/writing > that file. Do you mean to make sure the session cleaning thing doesn't > clean an active session? We could just check stat.m_time on the file or > something. > > The locking worries me a little bit because a lot of big sites have their > web pages on NFS-mounted partitions and the lockd/statd locking for NFS is > crappy. If we do need to lock, we might want to make sure we have some > way to define a session_directory in php3.ini and add a little hint > telling people to point this at a non-NFS location. locking is fairly important 'cause if you have a frameset with two "session" pages loading at the same time you might run into the situation where: 1. page one starts loading (session loaded) 2. page two loads quick (loads env, changes it, stores it) 3. page one finished loading and overwrites page twos (is that right;-) session vars. so, i think we need to do somathing "smart" about this. tc > > -Rasmus > > > -- > 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 > > > Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" Digital Collections Phone +49 40 235350 Fax +49 40 23535180 Hammerbrookstr. 93 20097 Hamburg / Germany -- 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