Re: Session management module - thoughts

From: Date: Sat, 29 May 1999 16:26:09 +0000
Subject: Re: Session management module - thoughts
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-6250@lists.php.net to get a copy of this message
I have been reading the discussion going on here and a had a few comments of my own. Read my comments below. 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. 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 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. 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 think we should concentrate on writing an API that will be suitable for > most situations. Something you could easily throw in and add session > support to your pages without having to go through documentationa and > trials and errors. After all, ASP's session API is extremely simplstic, > and I've yet to see anybody that had any complaints about it. ASP's > session API, as far as I know, is equivalent to this: > > session_start(); > session_variable($var); > session_end(); 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. 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. 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. 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. > If you want to build upon this API with some extra functions, I won't > object, even though I don't think it's worth it - complex stuff can always > be implemented at the PHP level, in PHP 4.0 more than ever before it's not > that much of an overhead. Since more complex requirements will usually go > hand in hand with more capable webmasters, the fear of them not being able > to install and configure phplib wears out. I am not sure how much PHP4 will remedy this situation, but for sites with lots of traffic this IS an issue! Maybe the thing to do would be to have two levels of session mgmt, basic and advanced. Zeev, please don't take this personally, this is not directed to you, but merely my thoughts! Thanks a bunch guys, -J -- ---------------------------------------- | http://motosite.com | | Your motorcycle resource on the web! | ---------------------------------------- | Juan A. Pons | | jpons@motosite.com | | '98 VFR800 - '88 NT650 (Hawk) | | AMA 368441 - HRCA | ---------------------------------------- -- 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

« previous php.dev (#6250) next »