On July 1, 2003 04:51 pm, Sterling Hughes wrote: > So of course we should just say 'screw performance' :) Again, if it > were useful, I would say "yes, totally." 100% and bucket o' bits. But > it doesn't give you anything, and it can be in PEAR/PECL for those who > really want it.
No, I certainly do not want to 'screw performance' as you've put it. Just playing a devil's advocate for the moment and putting things in perspective. The bottom line is that for most applications sqlite performance is adequate, same as files. However, when you need that 'ultimate' bit of speed you should consider something like shared memory. > I'm not suggesting it never exist (although I would be happier if that > were the case). What I am saying is that it should not exist by default > in PHP. Its shooting yourself in the foot without any real world reason > too. You and I both know that unless things change dramatically by the 5.0 release, PEAR & PECL are pretty much siberia. As people will begin to use sqlite eventually they'll surely consider using it for session managment. And implement a variety of classes etc... to do essentially what John has created for us in C. Why not save our users some time and have it bundled and avoid dosens of likely incompatible session managment formats. As long as files session handler is default this won't affect anyone and the only people who'll end up using sqlite session handling are the ones who think they need it. > > 3) Extremely easy to move sessions from one server to another > > tar cfz sessions.tar.gz sessions/ Certainly, except you forget few minor things, on most hosts all sessions are store in one place /tmp and even if you were to do tar cfz sessions.tar.gz /tmp/sess_*. You will pickup lot's of useless files and so on and even then you'll need to have permissions to execute the command, which many people do not. While with sqlite, all you need to a cp or php's copy() command. > > > 4) Marginally more secure then plain files > > Not at all. :) More files more better, you can have different > permissions on each file, rather than the neive implementation of using > one file for all sessions. Sure you can use save_path per virtual host, > but that's if you do it. The default implementation is less secure, and > that's what we have to count on. By default all sessions (files) are in one place /tmp for all users on the server. And most servers will allow users access to /tmp, meaning that any user with an account on the server can read anyone's session. But, security is a bad, point anyway most of the security issues that apply to files apply to sqlite as well. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
