[PHP-DEV] What to do with ext/snmp?

Mailing Lists php.internals
1

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]
<Issues · php/php-src · GitHub;
[2] <Issues · php/doc-en · GitHub;

Christoph

2

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>:

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

3

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]
<Issues · php/php-src · GitHub;
[2] <Issues · php/doc-en · GitHub;

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).

4

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]
<Issues · php/php-src · GitHub;
[2] <Issues · php/doc-en · GitHub;

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

5

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

6

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

7

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] PHP: rfc:deprecations_php_8_4
[2] Add composer.json for PIE support (ab978521) · Commits · Gina Peter Banyard / CSV PHP Extension · GitLab

8

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

9

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: Commits · php/pie · GitHub — 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: Xdebug: Support

mastodon: @derickr@phpc.social @xdebug@phpc.social

10

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

11

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

12

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

13

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