Re: Session management module - thoughts

On May 29, Zeev Suraski wrote: > 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. I'm sure I could contrive one if you want (how about this: maintaining one 'session' that shares values with other users (ie. a group) and one that saves user-specific data). Like I said, should be easy to add, and it doesn't change the basic operation, so I think we should add it. 'nuff said. > I'm not against adding hooks for future use, as long as people can still > use the KISS version without any added overhead. Right. > 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. We can't tell ISPs what do do. We're not really talking about moving files around, just allowing the user to say "put my PHP session data in this directory/file". This doesn't require any more goodwill on the ISPs side than letting their users fopen() a file and write to it does now. Getting them to configure a location for user's session data does. > 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. That's assuming that the ISP is running PHP as a module, and there are some large ones which do not, but which support PHP as CGI (which is absolutely reasonable and perfectly justifiable, and unlikely to change). And the policy I speak of doesn't make its distinction based on the userid running the process. If my website starts a process, it's still my process. :) We just need to support that case in addition to anything fancy. Doing it per-request (or per-Nth-request to minimize the performance impact) is just a fallback position. In fact, the per-Nth-request could probably be optimized to the-first-time-a-session-is-run-per-day using a file with its timestamp indicating the last time the cleanup was run. However, we should definitely provide a standalone "cleaner" that people with reasonable intelligence and control over their situation can simply run nightly (or however often they desire) via cron. This is undoubtedly the optimal configuration, but difficult to have automatically configured out of the box. 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