On Wed, 2014-10-01 at 14:26 +0200, Ferenc Kovacs wrote: > . > personally I think that a pecl extension needs to have stronger arguments > to be bundled with php-src than the fact that it would probably create a > bit more exposure for the ext. >
Fully agree and mind this: For an average user it doesn't really make a difference if we bundle it or not - linux distributions move even bundled extensions into own packages and package pecl ones, too. On Windows installers bundle pecl things too. For the extension maintainer not being bundled has the benefit of having its own release cycle. They are not bound to core PHP's rules and add minor features as they like and roll bug fixes as needed, while even fixes are simpler - they don't have to merge between as many branches. For core PHP having it in PECL has the benefit that a showstopper in the extension won't stop the PHP release. If the extension takes a week more that is fine. One might say that is a downside of using pecl that less people test it and in core the extension would receive more attention but I seriously doubt that many core developers enable all extensions (lester i.e. rightfully complains about the lack of attention on firebird) Now looking at this specific thing: PHP is a shared nothing environment for handling web requests. By having the isolation between request containers we can easily scale PHP by adding more machines, which is easy as we don't share state. sync does the opposite, its purpose is to break this isolation and offering a way to make request dependent on each other. There are cases where this is useful and it is great that we have a module with this option but in my opinion is not what PHP core should do. And yes, we have sysvmsg, sysvsem and sysvshm in the core distributions, but in my opinion more due to the fact that they predate pecl by a few years. johannes
signature.asc
Description: This is a digitally signed message part
