Re: A session class (was Re: [PEAR-DEV] Namespace issues)

*snip* > Also, not having a proper session handler means you have to recode > again and > again the way you want your session data stored. I would suggest that if you're finding yourself recoding again and again that it's your own fault. I manage my sessions from two include files (one has functions which include a configuration file). > That won't be a > problem if > you use MySQL because handlers for this DBS are widely available. But > if you > use Oracle and need to split your session data because of Oracle > limitation > on blob size (when not bound) this becomes a problem and you would > greatly > appreciate a properly written session handler. I don't talk about LDAP > and > so on. For instance, you might want to store your session data as XML > ? I don't see why this is an issue for PEAR. If you want to store session data as XML, or chop it up with substr, then do so. I notice a question mark on the end of the XML sentence. I havn't heard anyone complain about the lack of XML converting for data stored in sessions until today, then again, I guess it's only a "might" even in this case. > A good session handler needs containers. > In this way PHPlib session class was good. Auth in PHPLib was > depending > on > the session class. IMO, this is a requirement for a proper > authentication > system with modern features. I haven't used Stig's Auth class. Perhaps I haven't read this list close enough, but I wonder why there is such a cry for a grand "authentication system". I've found nothing wrong with just something like: if(!strcmp($_POST["login_username"], 'deekayen') && !strcmp($_POST["login_pass"], 'asdf')) { $_SESSION["user"]["username"] = 'deekayen'; $_SESSION["logged_in"] = true; Sure, it's a rudimentary example, but the text could be easily replaced by vars from a db query. Either a password matches or it doesn't and the logged_in session var should be enough basis to know whether the visitor is logged in or not. Again, something like that can be handled in a single include file. I'm not sure what else you could expect, other than maybe assigning all the $_SESSION vars to $vars, which I'd never do in any script I even remotely cared about execution time or overhead. Session "management" is already handled by the PHP engine. IMHO, suggesting having to "manage" sessions after the introduction of $_SESSION and all the things the engine does, is an insult to the work the core dev team did to make sessions as easy as they are. If you have a class file you created to manage your sessions, then use it, but I don't want to download it in my PHP distro. // end my $0.02 as a PEAR nobody David Norman - deekayen Get ready for a silly yahoo ad: __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com