Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » What to do with ext/snmp? »

What to do with ext/snmp?

php.internals

Christoph Becker

2 years ago
Hi all, it seems to me that we're pulling through ext/snmp without having any real expert of the protocol, let alone of the implementation. The extension has no code owner, and according to EXTENSIONS, it has no primary maintainer for more than ten years. Skimming through the commit log mostly shows general clean-ups and changes. And seeing that there have only two issues been reported on Github[1], I would conclude that either the extension just works as expected, or that it is not used much. A recent doc-bug report[2] makes me believe it's the latter. Personally, I barely know what SNMP is used for, but have no deeper understanding of that protocol, and I can remember that it took me quite a while to work out how to even set up a testing environment on Windows (without understanding the details). So the question is: do we have any SNMP experts (or some who want to become SNMP experts) around, who would want to take a look at the extension and its documentation? [1] <https://github.com/php/php-src/issues?q=is%3Aissue+label%3A%22Extension%3A+snmp%22+is%3Aopen> [2] <https://github.com/php/doc-en/issues/3690> Christoph

Michael Maroszek

2 years ago
We have switched to a userland library (https://github.com/FreeDSx/SNMP) due to crashes when using the internal SNMP extension in ZTS scenarios. It doesn't really answer your question, but maybe it fits category two, that usage is not very high or that people chose the pure PHP version. Michael Am Do., 29. Aug. 2024 um 19:53 Uhr schrieb Christoph M. Becker < cmbecker69@gmx.de>:

Calvin Buckley

2 years ago
On Aug 29, 2024, at 2:49 PM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> > Hi all, > > it seems to me that we're pulling through ext/snmp without having any > real expert of the protocol, let alone of the implementation. The > extension has no code owner, and according to EXTENSIONS, it has no > primary maintainer for more than ten years. Skimming through the commit > log mostly shows general clean-ups and changes. And seeing that there > have only two issues been reported on Github[1], I would conclude that > either the extension just works as expected, or that it is not used > much. A recent doc-bug report[2] makes me believe it's the latter. > > Personally, I barely know what SNMP is used for, but have no deeper > understanding of that protocol, and I can remember that it took me quite > a while to work out how to even set up a testing environment on Windows > (without understanding the details). > > So the question is: do we have any SNMP experts (or some who want to > become SNMP experts) around, who would want to take a look at the > extension and its documentation? > > [1] > <https://github.com/php/php-src/issues?q=is%3Aissue+label%3A%22Extension%3A+snmp%22+is%3Aopen> > [2] <https://github.com/php/doc-en/issues/3690> > > Christoph
I suspect it's not in high use either; Michael's reply suggests that. Maybe it could be spun out to PECL if there's a lack of interest in it, like imap was? (stupid speculation follows, people who know the history correct me) There are a few other extensions like that in ext/. I'm thinking a lot of them would have been in PECL or done in userland, but they were at the right place in the right time and ended up in ext/ instead. They might predate PECL (seems to be the case for SNMP), or wrapped a library hat was mature and well-used when it was written (seemed to the case for imap).

Jim Winstead

2 years ago
On Fri, Aug 30, 2024, at 9:54 AM, Calvin Buckley wrote:
> On Aug 29, 2024, at 2:49 PM, Christoph M. Becker <cmbecker69@gmx.de> wrote: >> >> Hi all, >> >> it seems to me that we're pulling through ext/snmp without having any >> real expert of the protocol, let alone of the implementation. The >> extension has no code owner, and according to EXTENSIONS, it has no >> primary maintainer for more than ten years. Skimming through the commit >> log mostly shows general clean-ups and changes. And seeing that there >> have only two issues been reported on Github[1], I would conclude that >> either the extension just works as expected, or that it is not used >> much. A recent doc-bug report[2] makes me believe it's the latter. >> >> Personally, I barely know what SNMP is used for, but have no deeper >> understanding of that protocol, and I can remember that it took me quite >> a while to work out how to even set up a testing environment on Windows >> (without understanding the details). >> >> So the question is: do we have any SNMP experts (or some who want to >> become SNMP experts) around, who would want to take a look at the >> extension and its documentation? >> >> [1] >> <https://github.com/php/php-src/issues?q=is%3Aissue+label%3A%22Extension%3A+snmp%22+is%3Aopen> >> [2] <https://github.com/php/doc-en/issues/3690> >> >> Christoph > > I suspect it's not in high use either; Michael's reply suggests that. > Maybe it could be spun out to PECL if there's a lack of interest in it, > like imap was?
That probably makes the most sense.
> (stupid speculation follows, people who know the history correct me) > > There are a few other extensions like that in ext/. I'm thinking a lot > of them would have been in PECL or done in userland, but they were at > the right place in the right time and ended up in ext/ instead. They > might predate PECL (seems to be the case for SNMP), or wrapped a library > hat was mature and well-used when it was written (seemed to the case for > imap).
Yes, ext/snmp probably goes back as far as the PHP 3 days (some guy named Rasmus was the original author). Perhaps if the effort from the PHP Foundation to build a next-generation PECL bears fruit, an even harder look can be taken at migrating out even more of the extensions still living in the php-src tree. With some robust CI, care could be made to make sure changes in php-src that impact extensions is noticed and dealt with, but spinning them out on their own might make them easier for more people to contribute to and maintain. Jim

Christoph Becker

2 years ago
On 30.08.2024 at 19:05, Jim Winstead wrote:
> Perhaps if the effort from the PHP Foundation to build a next-generation PECL bears fruit, an even harder look can be taken at migrating out even more of the extensions still living in the php-src tree. With some robust CI, care could be made to make sure changes in php-src that impact extensions is noticed and dealt with, but spinning them out on their own might make them easier for more people to contribute to and maintain.
Let's see what happened with the latest unbundled extensions: * PHP 7.4 unbundled ext/wddx, ext/recode and ext/interbase; neither has any release on PECL; they are effectively dead. At least the latter is still barely maintained outside of PECL. * PHP 8.0 unbundled ext/xmlrpc, which had three releases, and given that I'm listed as maintainer, I'd say that extension is also dead. * PHP 8.4 unbundled imap and pspell. These had two releases each, but I wouldn't hold my breath for a third. * PHP 8.4 also unbundled oci8 and pdo_oci. The former has already been partially maintained on PECL. Regarding the latter Christoph Jones is struggling to keep it somewhat maintained (due to lack of time). And generally, while there are many well maintained extensions on PECL, most (i.e. way more than half of the extension there) are outright abandoned, dead or half-dead, a lot of the latter barely kept alive by Remi Collet. A next generation PECL (installer) will not change this; only people who actively care about these extension could, if these people have knowledge of PHP extension development. I'm not saying that all PECL extensions deserve to be kept alive; there are good reasons for many to have been abandoned, e.g. because they were built on no longer supported libraries, are generally not useful anymore, or would be written in PHP nowadays (e.g. ext/dbase). 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. Christoph

Rob Landers

2 years ago
On Fri, Aug 30, 2024, at 20:13, Christoph M. Becker wrote:
> On 30.08.2024 at 19:05, Jim Winstead wrote: > > [snip] > > And generally, while there are many well maintained extensions on PECL, > most (i.e. way more than half of the extension there) are outright > abandoned, dead or half-dead, a lot of the latter barely kept alive by > Remi Collet. A next generation PECL (installer) will not change this; > only people who actively care about these extension could, if these > people have knowledge of PHP extension development. > > I'm not saying that all PECL extensions deserve to be kept alive; there > are good reasons for many to have been abandoned, e.g. because they were > built on no longer supported libraries, are generally not useful > anymore, or would be written in PHP nowadays (e.g. ext/dbase). > > 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. > > Christoph >
I went over to pecl to see how hard it was to create a new extension (after being prompted by Gina to submit my GMP operator stuff as a pecl extension). It appears to be very involved with a checkmark: "I have already discussed the topic of maintaining and/or adding a PECL extension on the pecl-dev@lists.php.net mailing list, and we determined it's time for me to have a PECL account" I, personally, can't imagine going through such a process. Not only do you have to convince gate-keepers you don't know to share your extension with (which higher up on the page says your code should be complete), but also convince end-users to use your extension. The barrier of entry is high, when it would be much easier to just create a repository and instructions; effectively making discovery of interesting php extensions nearly impossible. If you are using something like Docker containers, there is https://github.com/mlocati/docker-php-extension-installer which go so far as to install extensions from github (and apply patches) if they aren't updated/available in pecl (example: memcached + php 8 had an issue that was fixed on github but didn't get an update on pecl for nearly a year, IIRC). I'm pretty excited about pecl's replacement (how is that going anyway?) and hope it will be easier to create, maintain, and distribute extensions with. In other words, I emphatically agree that moving extensions out of core and into pecl would be a death sentence. — Rob

Derick Rethans

1 year ago
On Sat, 31 Aug 2024, Rob Landers wrote:
> On Fri, Aug 30, 2024, at 20:13, Christoph M. Becker wrote: > > 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. > > > > I went over to pecl to see how hard it was to create a new extension > (after being prompted by Gina to submit my GMP operator stuff as a > pecl extension). It appears to be very involved with a checkmark: > > "I have already discussed the topic of maintaining and/or adding a > PECL extension on the pecl-dev@lists.php.net mailing list, and we > determined it's time for me to have a PECL account" > > I, personally, can't imagine going through such a process. Not only do > you have to convince gate-keepers you don't know to share your > extension with (which higher up on the page says your code should be > complete), but also convince end-users to use your extension. The > barrier of entry is high, when it would be much easier to just create > a repository and instructions; effectively making discovery of > interesting php extensions nearly impossible.
The barrier of entry isn't really *that* bad. This process comes from PEAR, which most definitely required you to convince people. For PECL it was more meant as a "please also look over my code and license to see I'm not doing any stupid stuff". Ie: more as a help to contributors, than a gate. PECL accounts usually get approved pretty speedily. [snip[
> I'm pretty excited about pecl's replacement (how is that going > anyway?) and hope it will be easier to create, maintain, and > distribute extensions with.
It's going pretty well: https://github.com/php/pie/commits/main/ — I think there will soon be a "have a look at this" email. There is a tentative plan to have a first release to coincide with PHP 8.4 cheers, Derick
-- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social

Gina P. Banyard

1 year ago
On Friday, 30 August 2024 at 20:13, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> On 30.08.2024 at 19:05, Jim Winstead wrote: > > > Perhaps if the effort from the PHP Foundation to build a next-generation PECL bears fruit, an even harder look can be taken at migrating out even more of the extensions still living in the php-src tree. With some robust CI, care could be made to make sure changes in php-src that impact extensions is noticed and dealt with, but spinning them out on their own might make them easier for more people to contribute to and maintain. > > > Let's see what happened with the latest unbundled extensions: > > * PHP 7.4 unbundled ext/wddx, ext/recode and ext/interbase; neither has > any release on PECL; they are effectively dead. At least the latter is > still barely maintained outside of PECL. > > * PHP 8.0 unbundled ext/xmlrpc, which had three releases, and given that > I'm listed as maintainer, I'd say that extension is also dead. > > * PHP 8.4 unbundled imap and pspell. These had two releases each, but I > wouldn't hold my breath for a third. > > * PHP 8.4 also unbundled oci8 and pdo_oci. The former has already been > partially maintained on PECL. Regarding the latter Christoph Jones is > struggling to keep it somewhat maintained (due to lack of time). > > And generally, while there are many well maintained extensions on PECL, > most (i.e. way more than half of the extension there) are outright > abandoned, dead or half-dead, a lot of the latter barely kept alive by > Remi Collet. A next generation PECL (installer) will not change this; > only people who actively care about these extension could, if these > people have knowledge of PHP extension development. > > I'm not saying that all PECL extensions deserve to be kept alive; there > are good reasons for many to have been abandoned, e.g. because they were > built on no longer supported libraries, are generally not useful > anymore, or would be written in PHP nowadays (e.g. ext/dbase). > > 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. > > Christoph
Arguably this is because PECL is a pain to use as a maintainer and that we use PECL as a "graveyard". 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. 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] Or fix ext/dba and do a release without the absurd parameter type of dba_key_split(). 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. It would also permit extensions to follow semver while the engine continues to have its own versioning system. Having an extension be "bundled" doesn't even mean it is properly maintained, as neither ext/imap, ext/xmlrpc, or in this case ext/snmp are actually maintained. 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. Best regards, Gina P. Banyard [1] https://wiki.php.net/rfc/deprecations_php_8_4#xml_set_object_and_xml_set_handler_with_string_method_names [2] https://gitlab.com/Girgias/csv-php-extension/-/commit/ab978521e4d3bde15b73838d4605c5e5178ba082

Bilge

1 year ago
On Tue, 10 Sept 2024, 22:49 Gina P. Banyard, <internals@gpb.moe> wrote:
> > 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. > 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] > Or fix ext/dba and do a release without the absurd parameter type of > dba_key_split(). > 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. > It would also permit extensions to follow semver while the engine > continues to have its own versioning system. >
I really look forward to this. It will be a brave new world when PHP can ship without (m)any extensions and PIE can be used by anyone to customise what's loaded. Only then will the power of PHP's (existing) modularity be fully appreciated. Cheers, Bilge

Derick Rethans

1 year ago
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

Christoph Becker

1 year ago
On 11.09.2024 at 16:04, Derick Rethans wrote:
> 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.
We even made ext/json and ext/hash mandatory, so users can rely on the presence of these extensions. Christoph

Gina P. Banyard

1 year ago
On Wednesday, 11 September 2024 at 16:04, Derick Rethans <derick@php.net> wrote:
> 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.
Is XML parsing such an integral part of PHP in 2024? Debatable. And I am very much aware that not having extension bundled used to be an issue as hosting providers would not install PECL extensions. But we are working in a different environment today.
> > > 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".
We are on the internals mailing list, obviously "we" refers to internals here. Best regards, Gina P. Banyard

Arvids Godjuks

1 year ago
On Fri, 13 Sept 2024 at 17:18, Gina P. Banyard <internals@gpb.moe> wrote:
> > On Wednesday, 11 September 2024 at 16:04, Derick Rethans <derick@php.net> > wrote: > > 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. > > Is XML parsing such an integral part of PHP in 2024? Debatable. > And I am very much aware that not having extension bundled used to be an > issue as hosting providers would not install PECL extensions. > But we are working in a different environment today. >
Hello Gina, the answer is: YES When you do any sizeable number of 3rd party integrations that include any government services, XML and SOAP are guaranteed to be the APIs you must consume. Any data export is almost always giant XML documents.
-- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Telegram: @psihius https://t.me/psihius