Re: Session management module - thoughts

On Sat, 29 May 1999, Juan A. Pons wrote: > 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. > > I have to disagree. I was using phplib but moved away because of how > "heavy" it is. meaning that deploying a LARGE (read traffic not file > size) using PHPLIB was just not going to work. I rewrote session mgmt > system that is much more lightweight. Don't get me wrong I really like > PHPLIB, but it add too much overhead to our system. I think this SHOULD > really be a CORE differentiator between PHP and other systems such as > ASP or ColdFusion. Most people that have developed large sites using > thow two tehnologies have written their own session managment system, > simply becasue it just was not up to snuff, and relied on the NT > registry to save the data. That's clearly untrue. Most people don't need nor care about anything beyond the session management features they're given out of the box with ASP. I know many large web sites that rely on that and never found this support to be limited. Also, you have to realize that most people don't know nor care about how session management works. You should be thankful if they even know it relies on cookies. They just want to persist a variable across their web site, period. The number of people that do know and care about what's going on in their session management code are numerous, and are usually technically-capable enough to configure phplib. Performance won't be much of an issue with PHP 4.0. > I understand the need to cater to the average joe, and I also think this > is important, but PLEASE don't do this by sacrificing on the high end. As a rule, I'd think that the right thing to do is write something that's suitable for the average use, and not something fancy that nobody really uses. > As web sites and applications develop over time, sessions are going to > play a more and more important role on the eyes and minds of developers. > Implenting this in user space is fine, but you are doing it at the > expense of speed. For large sites this IS important. Not all that important, as I said. You can't compare PHP 4.0's performance with that of 3.0. > Beyond that I can't understand the thinking behind "dong it how > Microsoft does it is good enough" since when???? ASP Sucks, more because > of the patform that it runs into, second because it relies heavily in > MTS which is very unstable, but also because of it's session support. > Again it works well for small sites, but not heavy duty installatations. I never was a member in the 'ASP sucks' club, and technology-wise, there's a lot one can learn from Microsoft. The real question is 'since when is every thing that Microsoft makes NOT good enough?'. I rarely find people that actually blame Microsoft for what it has to be blamed; opensource junkies usually just bash it for the hell of it. Fact is that the vast majority of people will find ASP's session management framework to be all they could possibly ask for in a session management system, and a 5 year old can use it. Why add complexity and features where it's not necessary? As a side note, I've yet to crash MTS. MTS is nothing but a simple container for DCOM objects, if you write an unstable object (or use one) - it's your fault. MTS itself won't crash by the way, only the server for that particular object will. I'm not particularly fond of MTS conceptually, but I can't blame it for instability. > This is by far my experience, the only people that don't complain are > people that are "low end" developers, people that just finished reading > "learn ASP in 10 days!" and now they consider themselves expert web > developers. I've seen more than my share of those. I think a lot of > people here have. They're most people and most users. There are hundreds of thousands of PHP users, I'd guess most of them aren't computer science majors. But I'm saying and stressing again. Personally, I wouldn't care about anything beyond what ASP has to offer when it comes to session management. And I am a CS major. > A good session mgmt system should allow you to use different containers > for your data, starting with databse servers. This about this, can you > think of an easier way to build in scalability and redundancy to you > system by storing session info on a lightweight, fast, reliable database > system, place a whole bunch of webservers in front, that access the > session server, this way when a user comes to your site it does not > matter which web server they hit, as it will fetch the session info from > the session db. if a server goes down the loser loses at most the > current transaction but not the rest of their state info. This is how we > are doing it. Now try doing this with the built in session support in > ASP or CF. That's a great example for what I said. Most people don't care about that sort of scalability. Those who do will probably not use PHP anyway but a tailored solution. Either way, we could add this sort of stuff in the future, it's simply not important at this time. > In addition to cookie base session tracking, ASP also supports URL > based session IDs, I think this is also crucial as it has been reported > that as much as 40% of the users out there have cookies turned off. Where's that 40% figure from? I'd imagine it's totally bogus. Again, considering Microsoft requires cookies enabled for well over half of its web site, I truly doubt they intentionally give up 40% of their users. You can say whatever you want about Microsoft, but they're not keen on losing users. > a simple function like PHLIB's url() or purl() would not be too much to > ask from users to use in the URLs if they want sessions to work with > cookies disabled. They can choose to use it or not. That's true. I'd still avoid doing that since it renders the source much less readable, and also slightly decreases performance. > I am not sure how much PHP4 will remedy this situation, but for sites > with lots of traffic this IS an issue! It will, and thus it isn't. > Maybe the thing to do would be to have two levels of session mgmt, basic > and advanced. Again, as long as it doesn't harm the basic session management in any way, sure. If it hurts the basic session management development, though, by slowing down the development or by polluting it with many required arguments, I'm strictly against it. > Zeev, please don't take this personally, this is not directed to you, > but merely my thoughts! Ditto. Zeev -- 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