Re: Session management module - thoughts

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 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(); You don't need to use results or session handles (there can be just one session), you don't need to worry about cookies, you don't need to tell it where to save its information. You use it, simply, and it works. And even the most programming-disabled webmaster can figure out how to use this API. Even though this sounds like a marketing-oriented way to say things, I really think that it'll suit over 99% of the cases of session management. Again, it works for ASP. The only configurability I think we must have is pointing the server at where to save its session information, and at least in the initial phase, what I mean is a simple path pointer in the php.ini file. After we get that working, some might be interested in supporting storage devices other than files, but I really don't think that should bother the average user, and bare in mind that's the target we're addressing. 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. Note that writing this simple API raises a couple of problems, and I think it would be best for us to concentrate on them instead of dividing our efforts into a feature-full API that will never be properly implemented, at least not in the near future. The problem it raises as I see them: * Platform independent file locking * Cleanup of old sessions Unless somebody seriously objects to what I say here, I think we should begin to discuss how to go about doing that. Zeev On Fri, 28 May 1999, Sascha Schumann wrote: > On Fri, May 28, 1999 at 01:52:53PM -0400, Jim Winstead wrote: > > On May 28, Zeev Suraski wrote: > > > I'm not sure I'm following you, but what I have in mind is something every > > > John Doe newbie user can handle. Something along the lines of: > > > > > > session_start(); > > > > Ok, basic API: > > ======================================================================== > int session_start(string zone_path [, string CookieName [, string Id]]); > > This does the basic setup, imports previously registered variables, sends out > cookies and calls the garbage collection randomly. > > where > - zone_path is some path in your filesystem (I cannot think of a sensible > default here. anyone?) > > - CookieName is the name of the cookie session_start() checks for. If it is > set in the current context, we use the content of it as session id, > otherwise we create a new session id and send out a Set-Cookie HTTP header. > Defaults to "PHPSESSID" > > - Id overwrites the previously choosen session id > > ======================================================================== > session_destroy(int session_id); > > This destroys the session (e.g. for logout). > > ======================================================================== > > session_register(int session_id, string varname); > > Registers varname for being stored on page shutdown. > > -- > > Regards, > > Sascha Schumann > Consultant > > -- > 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 > > -- ----------------------------------------------------- Zeev Suraski <zeev@zend.com> For a PGP public key, finger bourbon@netvision.net.il -- 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