Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77739
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuQsNbdVrtxLcP5K0t8ShH0SbF=B0fW=+ou6o8r-0rO_UQ@mail.gmail.com>
References: <CAFp73Xv_bhs5zhA-7Fr4wchiEMCA76a9qMiSQA77CVf9-PnseA@mail.gmail.com>
 <472D9D28-4AD7-4B98-BBEE-A613F7FCA996@golemon.com> <CAFp73XtNLwpk3z=spnQa6KBJRj3MhA20uGXk03bzxvWgGZJSxA@mail.gmail.com>
 <004AF0D4-A329-46AB-BFE4-79CDE530BFA4@ajf.me> <CAFp73Xu0rJ1PcRzpdj+_cSguW-oN--=+Zg4gucw47gnZPw1h3g@mail.gmail.com>
 <CAH-PCH6vmVOwMQ8EGSK2mVvCZ=XkCzn7iCdTHaToVm_XA_svKA@mail.gmail.com>
 <1412168938.18768.36.camel@kuechenschabe> <CAMUwpuQsNbdVrtxLcP5K0t8ShH0SbF=B0fW=+ou6o8r-0rO_UQ@mail.gmail.com>
Date: Wed, 1 Oct 2014 14:20:47 -0400
Message-ID: <CAFp73Xu0tkG9aYL3F0c8vra4KwsZ1zJoAncxgZA8R9mHuy3tzw@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	Ferenc Kovacs <tyra3l@gmail.com>, Andrea Faulds <ajf@ajf.me>, Sara Golemon <php@golemon.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113491e44c496705046090d7
Subject: Re: [PHP-DEV] [RFC] Move pecl_sync to core
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--001a113491e44c496705046090d7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <jpauli@php.net> wrote:

> On Wed, Oct 1, 2014 at 3:08 PM, Johannes Schl=C3=BCter
> <johannes@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 havin=
g
> > 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 th=
e
> > extension won't stop the PHP release. If the extension takes a week mor=
e
> > 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 w=
e
> > 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
>



--=20
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada

--001a113491e44c496705046090d7--