Hi! > The benefit is that it can be tested properly and bugs discovered and > ironed out first. > This is not the sort of thing you want to get security bug reports the > day after its released in core. > If your ego is big enough you can guarantee you have tested this > thoroughly and want it to become the recommended way.. You have to be > damn sure you don't fuck it up. > > This is exactly the sort of thing that doesn't need to be developed in > the core tree, but can later be merged in once proven successful.
I see you point, and indeed, if we recommend something as a one-stop shop for security-sensitive area, we better be sure we do it right. But: are we really going to get enough testing if we put it out as PECL module? Also, we're not releasing 5.5 tomorrow, so we can have a lot of testing before. But if it's a non-core module, adoption would be much lower since apps could not rely on it being there even in 5.5. OTOH, PECL module that can be built in 5.3/5.4 too might be nice. Not everybody is going to upgrade to 5.5 soon, so having them participate would be good too. Maybe we could do it as a module and have it workable as PECL too for those who are not on 5.5? PHP solution is not really the same - if we have two separate codebases, nobody can be sure they actually do the same thing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
