Hi, Ferenc nailed why this RFC could be considered invalid. Maintenance burden and separate releases would be bad if tied to php-src. I'll update its status to declined.
Joe, as I said in the RFC, Mutex could only be supported through pthreads PECL. So your answer was still not 100% accurate from my POV. Julien, you know I don't feel offended with no-go feedbacks. All I want is a reasonable argumentation over a topic and general consensus. Cheers, On Wed, Oct 1, 2014 at 9:46 AM, Julien Pauli <jpa...@php.net> wrote: > On Wed, Oct 1, 2014 at 3:08 PM, Johannes Schlüter > <johan...@schlueters.de> wrote: > > 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. > > That's a good sum-up. > Locking is the opposite of PHP model, which is based on non-locking > model, fire-and-forget , scale easilly > > And seriously, if you need locking, mutexes etc... in PHP, then you > should probably write your stuff in C or Java. The PHP engine can't > fully support such concepts to provide them to userland, or at least > it won't be cheap in human effort to have such a thing reach a stable > state so that we can ship it into PHP. > > This is not a troll, or a "go away from PHP", please don't feel > offended , but PHP is just not designed to do that, this is not the > language you'll use when you face such problems. PHP is mature, but > still has a target, don't target something its not been designed for. > > > > Julien.Pauli > -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
