On 23/09/2024 07:14, Mike Schinkel wrote:
I think there's an impression that somehow by proposing that "we" add
some complex functionality "to the language", it will suddenly
attract developers and become stable and universally adopted; but
it's really the other way around: once there's a mature
implementation, and some people offering to maintain it, we can
consider moving it to the php-src repo, if that seems beneficial.
(And if other constraints are met, such as licensing.)
No, it is not "the other way around," it is *both*, and
mischaracterizing it to say that the only way hosting providers will
install something is if it becomes popular dismisses the valid
approach we've been advocating for, or at least for installations on a
reasonably widespread basis (~1/3rd of hosts or more)
I didn't say it needed to be *popular* before it moved to php-src, I
said it needed to be *mature*. There's two reasons I think that:
1) If being "bundled with PHP" is seen by users and hosts as a stamp of
approval, we don't want to put that stamp on something incomplete or
insecure. Nor do we want to add code to php-src which nobody is
volunteering to maintain.
2) Once an extension is moved into php-src, it is limited to PHP's
release cycle - 1 feature release per year, and breaking changes only in
major releases every 5 years or so. Early on in a project, it's common
to make many more incremental releases, and have short deprecation
periods while you experiment with the API.
What your dismissal ignores is that many hosts won't install something
unless a Framework or CMS requires or at least recommends it. And no
Framework or CMS that cares anything at all about risk management —
e.g. none with a large userbase — would require or at least recommend
an extension that is not bundled with PHP unless there is overwhelming
need for it and it targets a business vs. a technical need.
From what I can see, that's not actually true. WordPress, as discussed
elsewhere on this thread, has a very small list of *required*
extensions, and a much longer list of "highly recommended" ones.
https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions
As well as "bundled with PHP" extensions such as ext/curl and ext/dom,
the "highly recommended" list includes third-party / PECL extensions
such as igbinary and imagick.
On the hosting side, you mentioned Pantheon as an example, who I admit I
hadn't heard of before. I couldn't find a concise list of supported PHP
extensions, but did find this sample phpinfo() output:
https://v83-php-info.pantheonsite.io/
Among the installed PECL extensions are igbinary, imagick, mongodb,
msgpack, and oauth (which I note lists the version as "2.0.8dev").
Meanwhile, extensions which are bundled with PHP but *not* installed on
Pantheon include ext/dba, ext/gd, ext/ffi, ext/pspell, ext/sysvmsg,
ext/sysvsem, and ext/sysvshm
Clearly they have a policy for which extensions to install that is not
driven by whether they ship in php-src or PECL.
Then let us redirect our discussion as to whether it would be
beneficial to adopt wasmer-php into php-src repo, an objective list of
reasons it would not, if not, and an objective list of things it could
do to resolve those objections.
We can certainly do that. I'm not sure if there's a strict checklist,
but from my understanding, here's a few of the things we'd need to consider:
Licensing - Could PHP legally distribute the extension?
+ Wasmer-PHP is under the MIT License, so should be fine.
Stability & Maturity - Is the extension ready for production use? Is it
in a state where one feature release per year will be sufficient?
+ Wasmer-PHP describes itself as "complete and mature", so seems
promising at a glance.
Portability - does the extension support the platforms PHP supports?
- The compatibility table in the readme shows only Linux and Darwin on
amd64, with Windows support notably lacking. I'm not sure if this would
be considered a show-stopper.
Dependencies - What is needed to build and run it? Does that present any
licensing and portability concerns?
~ The extension itself seems to be self-contained C code (no C++, Rust,
or additional build tools). I haven't looked into the runtimes that it
would interface to.
Maintenance - is there somebody, and ideally several people, actively
responding to bug reports and compatibility updates? [See
https://github.com/php/php-src/blob/master/EXTENSIONS]
- This looks like a problem; the last release was over 3 years ago, and
there doesn't seem to have been any activity on the public repo since.
I also can't see any mention of it on the main Wasmer project site at
https://wasmer.io/products/runtime or the docs at
https://docs.wasmer.io/ The Wayback Machine shows the previous version
of their docs listed PHP as one of 8 "language integrations", but that
didn't carry across when they rewrote it last summer:
http://web.archive.org/web/20230608040408/https://docs.wasmer.io/ They
may be intending to come back to it later, but at the moment it seems
they are not dedicating any resources to it.
Regards,
--
Rowan Tommins
[IMSoP]
