Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125505
Date: Wed, 11 Sep 2024 15:04:41 +0100 (BST)
To: "Gina P. Banyard" <internals@gpb.moe>
cc: "Christoph M. Becker" <cmbecker69@gmx.de>, 
    Jim Winstead <jimw@trainedmonkey.com>, internals@lists.php.net
Subject: Re: [PHP-DEV] What to do with ext/snmp?
In-Reply-To: <Vk6SQnh3n0wWFW8G1Sop-c8QaZEZSbYfWa106Qax1FSiw3dRPzf4xRPu-I-v2HtpGvsFy-3X2x7pmMUzPpnhL_l7cLZ612ApF53Q0Bd50Xw=@gpb.moe>
Message-ID: <311efdd1-be06-e02a-29e3-a6c4b3a23334@php.net>
References: <9791621c-1313-4306-bc6a-5dd789f2b2df@gmx.de> <51FA7D6F-09F6-4267-9B57-5CBD42EA898C@cmpct.info> <57156bdd-cf93-404f-a10c-cd842bd7bb92@app.fastmail.com> <27cbee89-093f-4903-baec-a10058370c33@gmx.de>
 <Vk6SQnh3n0wWFW8G1Sop-c8QaZEZSbYfWa106Qax1FSiw3dRPzf4xRPu-I-v2HtpGvsFy-3X2x7pmMUzPpnhL_l7cLZ612ApF53Q0Bd50Xw=@gpb.moe>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: derick@php.net (Derick Rethans)

On Tue, 10 Sep 2024, Gina P. Banyard wrote:

> On Friday, 30 August 2024 at 20:13, Christoph M. Becker 
> <cmbecker69@gmx.de> wrote:
> 
> > Instead I'm saying that we should be careful to unbundle extensions. 
> > This should probably seen as a last resort if we absolutely can't 
> > maintain the extension any longer, or it doesn't make sense to do 
> > that. I'm not sure yet that ext/snmp falls into this category.
> > 
> > It's easy to vote "yes, unbundle this extension" if you've never 
> > used the extension and are not planning to do so in the future. It 
> > may be a death sentence, though.
> 
> Arguably this is because PECL is a pain to use as a maintainer and 
> that we use PECL as a "graveyard".

Although probably not frictionless, "pecl package" and uploading to the 
website isn't really a *pain*; at most a slight inconvenience. But as 
you know, PIE is on the way.

> But it is my biggest belief that most extensions would be better 
> outside the php-src repo and live in PECL so they could be updated 
> independently and not tied to the yearly PHP release schedule.

Some of that is true, but the issue is also that if they're in PECL, and 
PHP changes or "breaks" APIs, these extensions do not get updated. If 
they were in core, they still would have been. FOr many extensions, just 
*that* sort of maintenance is all they need.

> The fact that ext/cURL is not allowed to be updated in patch releases 
> any more means that features in libcurl take *ageees* to get exposed 
> in PHP. It also prevents extensions to be properly refactored because 
> they are bound to the same BC policy as the PHP engine, which doesn't 
> make a lot of sense to me. I could have cleaned-up ext/xml with all 
> the weird "string method callables" used with xml_set_object() in 1 
> week by releasing 3 different versions on PECL, instead of performing 
> some refactoring and 1 RFCs. [1]
>
> Having the DOM extension in PECL and be able to just change the 
> behaviour of the legacy classes to fix them instead of creating a 
> whole new hierarchy which slows down adoption could also have been 
> prevented (if it is a good idea) if it wasn't tied to PHP's release 
> schedule and BC policy.

But XML parsing is such an integral part of PHP, that this absolutely 
should be in core. For *many* users, if it's not in core, they can't use 
it. Or at least that used to be a big problem.

> Having added support for PIE for ext/csv, which was very easy, [2] I 
> hope when this tool is finally ready, and we ditch PECL, we will start 
> unbundling extensions so that they are not constrained by the PHP 
> Engine release cycle.

I believe that that is a decision for internals, not just "we".

cheers,
Derick