I probably don't have the background on msession that I need to make an intelligent comment, but here is an opinion of mine that is relatively on-topic.
The regular session implementation in PHP is extremely flexible, right? Sure, since you can write your own functions to do things such as store session data in a database, etc. However, there is *nothing* to help the average developer implement a professional-grade state management system out of the box. At least, not that I'm aware of. Everyone will happily explain how sessions in PHP work and then follow with a recommendation to *not* use sessions as they work out of the box, because data is stored in /tmp, etc. Take a competing product, such as ColdFusion, and configuring a database to use to maintain session data is a simple option. The functions that power the database session activity are part of the engine itself, and they're very quick and efficient. Every developer doesn't have to reinvent that wheel. Running a cluster of servers is cake. It sounds like msession has more of an enterprise perspective, and it might just have a few benefits worth considering. Session management is a huge deal in enterprise-level Web development, and I don't have to tell you guys how many developers have no idea what they're doing. If we have code that helps people do things the right way, I think it would go a long way in helping PHP. Why has no one suggested that features in msession be incorporated into the standard session module? I sure would hate to think that personality conflicts are getting in the way here. On a different topic, has there ever been a serious discussion about embedding commands in the PHP engine that allow for PHP administration? For example, an "administrator" PHP application would come bundled with PHP, and when dropped into document root, it would allow for Web-based administration of PHP. There are ways to secure this type of a system such that other PHP applications couldn't just use the same functions to perform their own rogue administration. This system could also allow us to provide a database abstraction layer to PHP without users have to write their own or copy someone else's in the business logic itself. We could leave that type of code in the engine and probably make it much faster. Anyway, some random thoughts from a listener. Chris [EMAIL PROTECTED] wrote: >I kind of went off in a huff yesterday with the whole PECL/pear issue with >msession, it's over and lets move on. I did, however, want to explain *why* >I think msession should be in the main code. > >In *big* websites, you need multiple web servers serving copies of the same >data in a load balanced environment. The PHP session code, in its native >state, can not manage this efficiently. You need some sort of external session >management system. > >Putting aside msession or SRM for the moment, the capability of linking >multiple PHP web servers is vital. As one scans the PHP site, it is not >immediately obvious how this is done, or that it can be done at all. You have >to do a bit of digging to figure out how to do it. > >I have worked as a software developer for almost 20 years now, and it has >become obvious to me that people in charge of making technology decisions are >not as technically savvy as we would like or is often assumed. They NEED to be >spoon-fed. If they have to look for something, they will probably assume it >does not exist and opt for the solutions that are marketed at them. > >Obviously I think msession is pretty good, but SRM works too. Regardless of >which, or even either, PHP needs to make an ?enterprise? statement. >Marginalizing this capability IMHO is not the right direction, I think there >should, in fact, be a stronger push for this sort of capability to be built in >by default. > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
