Re: [PHP-DEV] Are PECL modules preferable?

  109227
March 23, 2020 12:01 rowan.collins@gmail.com (Rowan Tommins)
On Mon, 23 Mar 2020 at 09:31, Mike Schinkel <mike@newclarity.net> wrote:

> > Assuming those 6 are all the PECL packages used, then that represents 1.5% > of available PECL packages, given there are currently 398 packages on PECL. > > Or said another way, there are 392 of 398 PECL packages that are > unavailable when hosting on this managed host. >
I think that's a pretty meaningless statistic. It's like comparing how many types of saucepan there are in your kitchen with how many are on sale, and saying "99% of saucepans are unavailable in my kitchen". The crucial point is that the host doesn't have a policy of only installing extensions which are bundled with PHP.
> And any newly added PECL packages are most likely to be in that > unavailable category >
Firstly, I'm not sure that's a reliable assumption - the package will be made available if there is demand for it, just like the (at least) 6 non-bundled extensions already enabled. Secondly, there's an implicit opposite assumption: that any newly added *bundled* extension *will* be available. I don't think that's a reliable assumption either, because it may still be disabled by default in whatever underlying package the host is building from. Ultimately, the barrier to having *any* functionality included on a managed platform like that is convincing the host that it will make their platform better. If there was a stable taint extension, and WordPress used it if it was installed, you could lobby WordPress hosts to enable it, regardless of whether it was bundled or in PECL. Note that bundled status makes even less difference to userland: unless the extension is *impossible* to disable (true of a handful of things like SPL), portable applications need to gracefully handle it not being there anyway. For example, a lot of code will detect if ext/curl is enabled, and try to fall back to URLs in file_get_contents and friends if not. Regards, -- Rowan Tommins [IMSoP]
  109233
March 23, 2020 16:03 mike@newclarity.net (Mike Schinkel)
> On Mar 23, 2020, at 8:01 AM, Rowan Tommins collins@gmail.com> wrote: > > On Mon, 23 Mar 2020 at 09:31, Mike Schinkel <mike@newclarity.net> wrote: > >> Assuming those 6 are all the PECL packages used, then that represents 1.5% >> of available PECL packages, given there are currently 398 packages on PECL. >> >> Or said another way, there are 392 of 398 PECL packages that are >> unavailable when hosting on this managed host. > > I think that's a pretty meaningless statistic. It's like comparing how many > types of saucepan there are in your kitchen with how many are on sale, and > saying "99% of saucepans are unavailable in my kitchen". > > The crucial point is that the host doesn't have a policy of only installing > extensions which are bundled with PHP.
My "meaningless" statistic was trying to make the point in a less direct way than I am doing now that your points about hosts installing a few PECL extensions are meaningless to the original point of this thread. The original point of this thread was to make the case that PECL extensions are _not_ a viable alternative to including features in core. It does not matter if a host installs _some_ unbundled PECL extensions. What matters is that the userland developer _cannot_choose_ to use a PECL extension if the managed host does not _already_ have it installed. And if a developer cannot choose a PECL extension, then it is a flawed argument that putting features into PECL vs. core is a viable alternative because putting them in PECL ensures many PHP developers will _never_ have access to them. You also brought up some orthogonal facts about extensions being bundled vs. unbundled extensions and how a managed host might choose to install some unbundled extensions. But while your points are true, there were irrelevant to the problems identified by this thread so mentioning them in essence hijacked this thread and refocused it on concerns unrelated to the original concern of this thread.
>> And any newly added PECL packages are most likely to be in that >> unavailable category > > Firstly, I'm not sure that's a reliable assumption - the package will be > made available if there is demand for it, just like the (at least) 6 > non-bundled extensions already enabled.
It is a *very* reliable assumption because status-quo at managed hosting companies is by far the default. Once a managed host has a working platform they are loath to change it because something might break and create dogged wntime for their customers that is potentially devastating for their business. Thus managed hosts rarely add things to their platform unless they need them to support their platform (like redis or new relic) or there is OVERWHELMING DEMAND in userland for adding them. So it is_literal() came out in a PECL extension and I went to a managed host and asked to use it they would politely tell me "sorry, we don't support that."
> Secondly, there's an implicit opposite assumption: that any newly added > *bundled* extension *will* be available. I don't think that's a reliable > assumption either, because it may still be disabled by default in whatever > underlying package the host is building from.
And here again status-quo is by far the default. Distros are not going to add potentially buggy extensions to their distros. They are going to wait until an extension has had plenty of time to mature _and_ that there is a significant number of developers that want the functionality. And distro maintainers are no easier to lobby to get PHP extensions included than the PHP community is to get features in core, and there are so many more than one you need to lobby. At least with PHP we are here and can lobby once, instead of having to go to many different organizations and/or maintainers/communities and lobby individually for each.
> Ultimately, the barrier to having *any* functionality included on a managed > platform like that is convincing the host that it will make their platform > better.
That is a false assertion. Managed hosts will upgrade to the latest version of PHP once the initial bugs are worked out. Full stop.
> If there was a stable taint extension, and WordPress used it if it > was installed, you could lobby WordPress hosts to enable it, regardless of > whether it was bundled or in PECL.
Theoretically I or someone else *could* lobby hosts to include that. But that is often harder to get them to change their platform than it is getting functionality added to PHP core itself — which I say rhetorically — and this lobbying has to be done on a host-by-host basis. IOW, lobbying managed hosts to change their platform is generally a fool's errand.
> Note that bundled status makes even less difference to userland:
And since the original message in this thread was about userland's access to PECL on a managed host, bringing up the distinction of bundled vs. unbundled was an orthogonal distraction. Or said another way, you made a distinction without a difference regarding the concerns of this thread.
> portable applications need to gracefully handle it not being there > anyway. For example, a lot of code will detect if ext/curl is enabled, > and try to fall back to URLs in file_get_contents and friends if not.
Yes, when an extension is missing developers have to deal with it. Which is exactly the point. If a feature is useful to a broad range of PHP developer then choosing to put it in PECL instead of in core means that many PHP will never be able to access it and will have to each write a workaround — if possible — or just do without the feature entirely. IOW, putting in PECL creates PHP "haves" and PHP "have nots." Said another way, PECL extensions balkanize PHP and create hundreds of different flavors of PHP that have to be dealt with individually by each developer or at least each framework/CMS. Which is ironically something that people on this list have argued strenuously against when the topic of declare()s and editions have been discussed. -Mike P.S. Which is (I think) why Ben brought up the idea of a userland-controllable extension mechanism and why I followed up with a proposal to suggest PHP add support for allowing userland to load and run WASM packages.
  109234
March 23, 2020 17:00 mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=)
On Mon, Mar 23, 2020 at 4:03 PM Mike Schinkel <mike@newclarity.net> wrote:

> Once a managed host has a working platform they are loath to change it > because something might break and create dogged wntime for their customers > that is potentially devastating for their business. > > Thus managed hosts rarely add things to their platform unless they need > them to support their platform (like redis or new relic) or there is > OVERWHELMING DEMAND in userland for adding them. >
It is utterly unreasonable to expect to change what is or isn't bundled in a project because you managed host of choice is afraid of breaking something. Also, as it has been said before, just because something is bundled it doesn't mean that your managed host of choice won't disable it during compile time. Find a host that lets you control your PHP installation the way you need it. Not the other way around. Regards, Pedro
  109235
March 23, 2020 17:10 mike@newclarity.net (Mike Schinkel)
> On Mar 23, 2020, at 1:00 PM, Pedro Magalhães <mail@pmmaga.net> wrote: > >> On Mon, Mar 23, 2020 at 4:03 PM Mike Schinkel <mike@newclarity.net> wrote: >> Once a managed host has a working platform they are loath to change it because something might break and create dogged wntime for their customers that is potentially devastating for their business. >> >> Thus managed hosts rarely add things to their platform unless they need them to support their platform (like redis or new relic) or there is OVERWHELMING DEMAND in userland for adding them. > > It is utterly unreasonable to expect to change what is or isn't bundled in a project because you managed host of choice is afraid of breaking something.
What? I said nothing about bundling related to hosts. What I said is that hosts don't add PECL extensions to their managed platform unless they make the decision to do so for all of their platform, and that decision is not because some new feature just showed up on PECL and a few of their customers want to use it.
> Also, as it has been said before, just because something is bundled it doesn't mean that your managed host of choice won't disable it during compile time.
And that I agree with. But you just supported my thesis that including a feature PECL is not a viable alternative to providing functionality in PHP core.
> Find a host that lets you control your PHP installation the way you need it. Not the other way around.
That is a utopian sentiment, but not valid in the corporate world that uses managed hosting because they are focused on operating their business and not on having to spend time, resources and management expertise in securing and running servers on the Internet. -Mike
  109244
March 23, 2020 18:22 r@roze.lv ("Reinis Rozitis")
> -----Original Message----- > From: Mike Schinkel > > That is a utopian sentiment, but not valid in the corporate world that uses > managed hosting because they are focused on operating their business and > not on having to spend time, resources and management expertise in > securing and running servers on the Internet.
Not sure if using "corporate world" in this argument is good either. "Corporate world" typically doesn't want to change anything hence ~50% of the world still runs on PHP5. You will probably get more usage/adoption of the particular new feature in a php5/7 compatible php pecl extension rather than waiting for a managed hosting to upgrade to PHP 8/NEXT (see something like imagick, memcache or redis - not in a core at all, but probably rarely any host without those). As for the "ensures many PHP developers will _never_ have access to them" - nowadays when everything can run in containerized environments where you can setup/configure php in whatever manner you like or the software needs, it usually isn't a problem anymore. rr
  109246
March 23, 2020 19:07 larry@garfieldtech.com ("Larry Garfield")
On Mon, Mar 23, 2020, at 1:22 PM, Reinis Rozitis wrote:
> > -----Original Message----- > > From: Mike Schinkel > > > > That is a utopian sentiment, but not valid in the corporate world that uses > > managed hosting because they are focused on operating their business and > > not on having to spend time, resources and management expertise in > > securing and running servers on the Internet. > > Not sure if using "corporate world" in this argument is good either. > "Corporate world" typically doesn't want to change anything hence ~50% > of the world still runs on PHP5. > > You will probably get more usage/adoption of the particular new feature > in a php5/7 compatible php pecl extension rather than waiting for a > managed hosting to upgrade to PHP 8/NEXT (see something like imagick, > memcache or redis - not in a core at all, but probably rarely any host > without those). > > As for the "ensures many PHP developers will _never_ have access to > them" - nowadays when everything can run in containerized environments > where you can setup/configure php in whatever manner you like or the > software needs, it usually isn't a problem anymore.
Those two arguments seem contradictory. The people who can happily containerize things and pick their own version are the ones who could also toss in another PECL library if they wanted; and the ones on crappy shared (or corporate IT legacy) hosting where they don't control the version also couldn't control the PECL libraries they have. People stuck in the past are stuck in the past. :-) Also, hosts that run modern PHP versions are way waaaaay more readily available than they once were: http://phpversions.info/new-and-shiny/ At this point, anyone stuck on an old PHP version either has ample ability to move to a host that isn't robbing them blind, or else they're trapped by corporate IT policies that wouldn't allow anything written today to be used for 5 years anyway, no matter where it is. --Larry Garfield
  109237
March 23, 2020 17:25 rowan.collins@gmail.com (Rowan Tommins)
On Mon, 23 Mar 2020 at 16:04, Mike Schinkel <mike@newclarity.net> wrote:

> > The original point of this thread was to make the case that PECL > extensions are _not_ a viable alternative to including features in core. > > It does not matter if a host installs _some_ unbundled PECL extensions. > What matters is that the userland developer _cannot_choose_ to use a PECL > extension if the managed host does not _already_ have it installed. >
My point is that they cannot choose which "bundled" extensions they use either. That choice is entirely up to the managed host.
> You also brought up some orthogonal facts about extensions being bundled > vs. unbundled extensions and how a managed host might choose to install > some unbundled extensions. But while your points are true, there were > irrelevant to the problems identified by this thread so mentioning them in > essence hijacked this thread and refocused it on concerns unrelated to the > original concern of this thread. >
They are neither orthogonal nor irrelevant, they are directly addressing the question "does bundling an extension give an advantage over having it in PECL?"
> Once a managed host has a working platform they are loath to change it > because something might break and create downtime for their customers that > is potentially devastating for their business. >
This is true of bundled extensions as well as PECL ones.
> Thus managed hosts rarely add things to their platform unless they need > them to support their platform (like redis or new relic) or there is > OVERWHELMING DEMAND in userland for adding them. >
This is true of bundled extensions as well as PECL ones.
> So it is_literal() came out in a PECL extension and I went to a managed > host and asked to use it they would politely tell me "sorry, we don't > support that." >
This could well be true of bundled extensions as well as PECL ones.
> Distros are not going to add potentially buggy extensions to their > distros. They are going to wait until an extension has had plenty of time > to mature _and_ that there is a significant number of developers that want > the functionality. >
This is true of bundled extensions as well as PECL ones.
> > Ultimately, the barrier to having *any* functionality included on a > managed > > platform like that is convincing the host that it will make their > platform > > better. > > That is a false assertion. Managed hosts will upgrade to the latest > version of PHP once the initial bugs are worked out. Full stop. >
Upgrading to the latest version of PHP does not automatically give you all bundled extensions. This is the key point I'm trying to get across here. Every extension "bundled with" PHP, with a tiny set of exceptions, is optional. The only way to get around that is to make the feature *mandatory*, that is: * part of the absolute core of the language grammar or engine * part of an existing mandatory extension like ext/standard or ext/spl * a new extension which is not just bundled but which cannot be disabled in the build configuration There are a few cases where that's a reasonable thing to do, but most of the time when people are discussing "PECL vs core", they are talking about a new extension, which would be optional anyway.
> Yes, when an extension is missing developers have to deal with it. Which is exactly the point.
Exactly what point? The example I gave was ext/curl, which doesn't require anything from PECL, it's just optional in the build. If you're saying we should move away from the language being modular, and having optional extensions, then we can discuss that. But that's a very different discussion from "PECL vs core". Regards, -- Rowan Tommins [IMSoP]
  109239
March 23, 2020 17:34 mike@newclarity.net (Mike Schinkel)
Rowan,

Based on your responses now I am not at all sure what you were driving at.

I think you are making detail points because of nuances of PECL and bundled vs. unbundled etc, while I was trying to make a higher level case.

So let me restate the thesis:

"When discussing a potential new feature suggesting that it be implemented in a way that it might not actually be available (via PECL, unbundled, disabled, whatever) is not a viable alternative for many PHP developers unless integral to the feature is a need to make it optional."

-Mike

> On Mar 23, 2020, at 1:25 PM, Rowan Tommins collins@gmail.com> wrote: > > On Mon, 23 Mar 2020 at 16:04, Mike Schinkel <mike@newclarity.net> wrote: > >> >> The original point of this thread was to make the case that PECL >> extensions are _not_ a viable alternative to including features in core. >> >> It does not matter if a host installs _some_ unbundled PECL extensions. >> What matters is that the userland developer _cannot_choose_ to use a PECL >> extension if the managed host does not _already_ have it installed. >> > > > My point is that they cannot choose which "bundled" extensions they use > either. That choice is entirely up to the managed host. > > > >> You also brought up some orthogonal facts about extensions being bundled >> vs. unbundled extensions and how a managed host might choose to install >> some unbundled extensions. But while your points are true, there were >> irrelevant to the problems identified by this thread so mentioning them in >> essence hijacked this thread and refocused it on concerns unrelated to the >> original concern of this thread. >> > > > They are neither orthogonal nor irrelevant, they are directly addressing > the question "does bundling an extension give an advantage over having it > in PECL?" > > > >> Once a managed host has a working platform they are loath to change it >> because something might break and create downtime for their customers that >> is potentially devastating for their business. >> > > > This is true of bundled extensions as well as PECL ones. > > > >> Thus managed hosts rarely add things to their platform unless they need >> them to support their platform (like redis or new relic) or there is >> OVERWHELMING DEMAND in userland for adding them. >> > > > This is true of bundled extensions as well as PECL ones. > > > >> So it is_literal() came out in a PECL extension and I went to a managed >> host and asked to use it they would politely tell me "sorry, we don't >> support that." >> > > > This could well be true of bundled extensions as well as PECL ones. > > > >> Distros are not going to add potentially buggy extensions to their >> distros. They are going to wait until an extension has had plenty of time >> to mature _and_ that there is a significant number of developers that want >> the functionality. >> > > > This is true of bundled extensions as well as PECL ones. > > > >>> Ultimately, the barrier to having *any* functionality included on a >> managed >>> platform like that is convincing the host that it will make their >> platform >>> better. >> >> That is a false assertion. Managed hosts will upgrade to the latest >> version of PHP once the initial bugs are worked out. Full stop. >> > > > Upgrading to the latest version of PHP does not automatically give you all > bundled extensions. > > This is the key point I'm trying to get across here. Every extension > "bundled with" PHP, with a tiny set of exceptions, is optional. > > > The only way to get around that is to make the feature *mandatory*, that is: > > * part of the absolute core of the language grammar or engine > * part of an existing mandatory extension like ext/standard or ext/spl > * a new extension which is not just bundled but which cannot be disabled in > the build configuration > > There are a few cases where that's a reasonable thing to do, but most of > the time when people are discussing "PECL vs core", they are talking about > a new extension, which would be optional anyway. > > >> Yes, when an extension is missing developers have to deal with it. Which > is exactly the point. > > Exactly what point? The example I gave was ext/curl, which doesn't require > anything from PECL, it's just optional in the build. > > If you're saying we should move away from the language being modular, and > having optional extensions, then we can discuss that. But that's a very > different discussion from "PECL vs core". > > > Regards, > -- > Rowan Tommins > [IMSoP]
  109240
March 23, 2020 17:51 ben@benramsey.com (Ben Ramsey)
> On Mar 23, 2020, at 12:34, Mike Schinkel <mike@newclarity.net> wrote: > > Rowan, > > Based on your responses now I am not at all sure what you were driving at. > > I think you are making detail points because of nuances of PECL and bundled vs. unbundled etc, while I was trying to make a higher level case. > > So let me restate the thesis: > > "When discussing a potential new feature suggesting that it be implemented in a way that it might not actually be available (via PECL, unbundled, disabled, whatever) is not a viable alternative for many PHP developers unless integral to the feature is a need to make it optional.”
I think Rowan is making the point that *most* of the features found in the core PHP distribution are *optional*. Distributions and hosts are choosing to enable them. There are very few things in the core distribution that cannot be disabled at build time. I’ve run into this numerous times in my userland OSS libraries. It came up recently with the ctype functions. Someone’s host had these disabled, for whatever reason, so I had to use a polyfill library to provide the functionality, for those cases. Cheers, Ben
  109242
March 23, 2020 18:09 mike@newclarity.net (Mike Schinkel)
> On Mar 23, 2020, at 1:51 PM, Ben Ramsey <ben@benramsey.com> wrote: > >> On Mar 23, 2020, at 12:34, Mike Schinkel <mike@newclarity.net> wrote: >> >> Rowan, >> >> Based on your responses now I am not at all sure what you were driving at. >> >> I think you are making detail points because of nuances of PECL and bundled vs. unbundled etc, while I was trying to make a higher level case. >> >> So let me restate the thesis: >> >> "When discussing a potential new feature suggesting that it be implemented in a way that it might not actually be available (via PECL, unbundled, disabled, whatever) is not a viable alternative for many PHP developers unless integral to the feature is a need to make it optional.” > > > I think Rowan is making the point that *most* of the features found in the core PHP distribution are *optional*. Distributions and hosts are choosing to enable them. There are very few things in the core distribution that cannot be disabled at build time. > > I’ve run into this numerous times in my userland OSS libraries. It came up recently with the ctype functions. Someone’s host had these disabled, for whatever reason, so I had to use a polyfill library to provide the functionality, for those cases.
Which makes an even stronger case for why a userland accessible extension mechanism is needed. Did you see my reply to you about the various options for userland extensibility with the (IMO) most promising one being adding support for WASM to PHP core? -Mike
  109243
March 23, 2020 18:11 ben@benramsey.com (Ben Ramsey)
> On Mar 23, 2020, at 13:09, Mike Schinkel <mike@newclarity.net> wrote: > >> On Mar 23, 2020, at 1:51 PM, Ben Ramsey <ben@benramsey.com> wrote: >> >>> On Mar 23, 2020, at 12:34, Mike Schinkel <mike@newclarity.net> wrote: >>> >>> Rowan, >>> >>> Based on your responses now I am not at all sure what you were driving at. >>> >>> I think you are making detail points because of nuances of PECL and bundled vs. unbundled etc, while I was trying to make a higher level case. >>> >>> So let me restate the thesis: >>> >>> "When discussing a potential new feature suggesting that it be implemented in a way that it might not actually be available (via PECL, unbundled, disabled, whatever) is not a viable alternative for many PHP developers unless integral to the feature is a need to make it optional.” >> >> >> I think Rowan is making the point that *most* of the features found in the core PHP distribution are *optional*. Distributions and hosts are choosing to enable them. There are very few things in the core distribution that cannot be disabled at build time. >> >> I’ve run into this numerous times in my userland OSS libraries. It came up recently with the ctype functions. Someone’s host had these disabled, for whatever reason, so I had to use a polyfill library to provide the functionality, for those cases. > > Which makes an even stronger case for why a userland accessible extension mechanism is needed. > > Did you see my reply to you about the various options for userland extensibility with the (IMO) most promising one being adding support for WASM to PHP core?
Yes, I did. I don’t know enough about WASM right now to comment on it. Cheers, Ben
  109247
March 23, 2020 19:08 rowan.collins@gmail.com (Rowan Tommins)
On Mar 23, 2020, at 1:51 PM, Ben Ramsey <ben@benramsey.com> wrote:

> > I think Rowan is making the point that *most* of the features found in > the core PHP distribution are *optional*. Distributions and hosts are > choosing to enable them. There are very few things in the core distribution > that cannot be disabled at build time. > > > > I’ve run into this numerous times in my userland OSS libraries. It came > up recently with the ctype functions. Someone’s host had these disabled, > for whatever reason, so I had to use a polyfill library to provide the > functionality, for those cases. >
Thank you, yes, that's exactly what I'm saying. PHP is, right now, a modular product. As long as that's true, there will be hosts who disable features you wish they wouldn't. Some of those can be polyfilled directly (e.g. ctype), some have to be painfully worked around (e.g. curl), and some are pretty much impossible because no userland equivalent exists. On Mon, 23 Mar 2020 at 18:09, Mike Schinkel <mike@newclarity.net> wrote:
> Which makes an even stronger case for why a userland accessible extension > mechanism is needed. >
If you're using a fully-managed hosting service, you will always be severely limited in what you can enable or install - some of the WordPress hosts you listed don't even let you upload arbitrary PHP, only vetted WordPress themes and plugins. If you're using a more flexible shared hosting service, the problem might instead be that the host lets you run arbitrary userland code but not switch on extra extensions. In that case, features that make more things possible from userland would be useful for those extensions which can't currently be polyfilled. The challenge would be getting something flexible enough to be more useful than just writing normal PHP, but secure, stable, and sandboxed enough that shared hosts would let you mess around with it. Regarding choice of language for that mechanism, I'm not sure we need to look any further than PHP itself: what we're really talking about is making facilities available to the average user that are currently only available to extension developers. We've already made huge strides in one big advantage, which is speed - if they were starting today, I wonder if the Phalcon team would bother inventing Zephir, or if they'd just design the framework with OpCache pre-loading in mind. Regards, -- Rowan Tommins [IMSoP]
  109250
March 23, 2020 19:55 mike@newclarity.net (Mike Schinkel)
> On Mar 23, 2020, at 3:08 PM, Rowan Tommins collins@gmail.com> wrote: > > On Mar 23, 2020, at 1:51 PM, Ben Ramsey <ben@benramsey.com> wrote: > >>> I think Rowan is making the point that *most* of the features found in >> the core PHP distribution are *optional*. Distributions and hosts are >> choosing to enable them. There are very few things in the core distribution >> that cannot be disabled at build time. >>> >>> I’ve run into this numerous times in my userland OSS libraries. It came >> up recently with the ctype functions. Someone’s host had these disabled, >> for whatever reason, so I had to use a polyfill library to provide the >> functionality, for those cases. > > > Thank you, yes, that's exactly what I'm saying. PHP is, right now, a > modular product.
While that it technically true, but in practice there is very little variance across WordPress managed hosts. Why? WordPress has documented its required extensions and there are rarely motivations for hosts to go beyond that when they are offering WordPress hosting: https://make.wordpress.org/hosting/handbook/handbook/server-environment/#php-extensions And I assume Drupal has similar established extension requirements.
> As long as that's true, there will be hosts who disable features you wish > they wouldn't. Some of those can be polyfilled directly (e.g. ctype), some > have to be painfully worked around (e.g. curl), and some are pretty much > impossible because no userland equivalent exists.
Generally that is not the issue with WordPress. Most managed WordPress hosts support the required ones, and few managed WordPress hosts support anything more except for when they need the support for their own platform, which is the case with Pantheon's extra extensions. And even if one host does support more extensions, no responsible WordPress developer would use them (unless they are highly specific to business requirements) because if they did it could lock them into not being able to move off that managed host if needed. So yes PHP is technical modular, but among managed hosts PHP is a monolith. And yes, this is about WordPress, but the constraints of using WordPress' on managed hosts was the original premise of this thread.
> Regarding choice of language for that mechanism, I'm not sure we need to > look any further than PHP itself: what we're really talking about is making > facilities available to the average user that are currently only available > to extension developers.
If that is the case then we probably need to add more improvements to the PHP language than have been added in the past 10 years because there is so much you can't reasonably do in PHP. One example would be to adopt the gradual typing of Hack to allow for significant performance improvement. Said another way, I don't see PHP coming close to the performance of Rust anytime in the next (few) decade(s).
> We've already made huge strides in one big > advantage, which is speed - if they were starting today, I wonder if the > Phalcon team would bother inventing Zephir, or if they'd just design the > framework with OpCache pre-loading in mind.
It is notable you mention Zephir but make no mention to WASM, which is what I pointed to as the most promising extension mechanism I currently see on the horizon. (BTW, I am really happy they created Zephir, but only because it is helpful for a project I am working on in ways that would probably not be applicable to discuss on the list.) But why no reference to WASM? WASM would let us write extensions in many languages. Even better, we could write a PHP-to-WASM compiler for a WASM-specific dialect of PHP.
> > > Regards, > -- > Rowan Tommins > [IMSoP]
  109251
March 23, 2020 20:03 ben@benramsey.com (Ben Ramsey)
> On Mar 23, 2020, at 14:55, Mike Schinkel <mike@newclarity.net> wrote: > >> We've already made huge strides in one big >> advantage, which is speed - if they were starting today, I wonder if the >> Phalcon team would bother inventing Zephir, or if they'd just design the >> framework with OpCache pre-loading in mind. > > It is notable you mention Zephir but make no mention to WASM, which is what I pointed to as the most promising extension mechanism I currently see on the horizon. > > (BTW, I am really happy they created Zephir, but only because it is helpful for a project I am working on in ways that would probably not be applicable to discuss on the list.) > > But why no reference to WASM? WASM would let us write extensions in many languages. Even better, we could write a PHP-to-WASM compiler for a WASM-specific dialect of PHP. >
The reference to Zephir here is about speed of the engine. If the folks who created Phalcon were to create it today (on PHP 7), would they have decided to create it as an extension and bother creating Zephir? I can’t speak for anyone from that project, but this was what I was driving at by my “advocate for implementing in userland” comment. The engine is fast. Implementing in C does not provide as significant a performance boost (vs. implementing in userland) as it used to (YMMV depending on the workloads you’re processing). Cheers, Ben
  109252
March 23, 2020 20:08 mike@newclarity.net (Mike Schinkel)
Just as a follow up where I just asked Greg Anderson of Pantheon on their community Slack in the #community channel about supporting new versions of PHP and ability to install PECL extensions. It pretty much follows exactly what I have been saying:

=====================
Greg Anderson [Pantheon]: 
=====================
In terms of upgrading PHP, it's a mixed bag. Some hosts are slow, some are fast. Pantheon is pretty quick about updating patch releases. Minor releases, though, are usually not prioritized right away because it is assumed that most customers won't want to upgrade to the latest patch release until Drupal / WordPress supports it.

There's also the question of how much work it is to upgrade. 7.0, 7.2, and 7.4 required some fixing.  7.1 and 7.3 pretty much worked out of the box.

In instanced where there's very little work to be done, we usually can slip it onto the platform right away. If it takes some time, then the card goes to product, and product prioritizes it against all of our other features.

-------
Regarding PECL, no, you cannot add any compiled extensions on Pantheon. You have to use what we package; you can see what's available from this php-info link: https://v74-php-info.pantheonsite.io/

If a lot of customers request an extension, then Product might go ahead and give us a card to add it to the platform.

It's not much work to add an extension, but there's a maintenance cost, so really not very many of these get added (beyond the base set already identified)
-------

Sure, you can buy a nice Digital Ocean container and put whatever you want on it. Our customers want something different, though, so there's a trade-off.

Maybe if PHP came with a "bundled" distro with a base set of PECL extensions tested and added, managed hosts would decide to pick that up.
=====================


-Mike
P.S. Pantheon is an enterprise-level WordPress host that my company has been using and recommending since 2014 because of how much of the pain they handle that is associated with hosting a secure and performance WordPress server that uses Git directly for version control and provides a test-stage-live environment for every "site."
  109253
March 23, 2020 20:13 ben@benramsey.com (Ben Ramsey)
> On Mar 23, 2020, at 15:08, Mike Schinkel <mike@newclarity.net> wrote: > > Maybe if PHP came with a "bundled" distro with a base set of PECL extensions tested and added, managed hosts would decide to pick that up.
This is pretty much the role the packagers play for all the various OS distributions. Cheers, Ben
  109254
March 23, 2020 20:13 larry@garfieldtech.com ("Larry Garfield")
On Mon, Mar 23, 2020, at 3:08 PM, Mike Schinkel wrote:
> Just as a follow up where I just asked Greg Anderson of Pantheon on > their community Slack in the #community channel about supporting new > versions of PHP and ability to install PECL extensions. It pretty much > follows exactly what I have been saying: > > ===================== > Greg Anderson [Pantheon]: > ===================== > In terms of upgrading PHP, it's a mixed bag. Some hosts are slow, some > are fast. Pantheon is pretty quick about updating patch releases. Minor > releases, though, are usually not prioritized right away because it is > assumed that most customers won't want to upgrade to the latest patch > release until Drupal / WordPress supports it. > > There's also the question of how much work it is to upgrade. 7.0, 7.2, > and 7.4 required some fixing. 7.1 and 7.3 pretty much worked out of > the box. > > In instanced where there's very little work to be done, we usually can > slip it onto the platform right away. If it takes some time, then the > card goes to product, and product prioritizes it against all of our > other features. > > ------- > Regarding PECL, no, you cannot add any compiled extensions on Pantheon. > You have to use what we package; you can see what's available from this > php-info link: https://v74-php-info.pantheonsite.io/ > > If a lot of customers request an extension, then Product might go ahead > and give us a card to add it to the platform. > > It's not much work to add an extension, but there's a maintenance cost, > so really not very many of these get added (beyond the base set already > identified) > ------- > > Sure, you can buy a nice Digital Ocean container and put whatever you > want on it. Our customers want something different, though, so there's > a trade-off. > > Maybe if PHP came with a "bundled" distro with a base set of PECL > extensions tested and added, managed hosts would decide to pick that up. > =====================
Platform.sh, the managed host I work for, has offered every version of PHP since 7.1 day-of-release, and we also have a long list of available PECL extensions that can be enabled by adding a line to a YAML file. We also have a built-in build pipline where you can download and compile/install most other extensions as desired. We're also a Git-based host with every Git branch able to be a running environment. It's not that managed hosts can't make new-stuff easily available. It's that many don't. But enough do that if you need the latest-and-greatest, you have plenty of options. --Larry Garfield
  109255
March 23, 2020 20:20 mike@newclarity.net (Mike Schinkel)
> On Mar 23, 2020, at 4:13 PM, Larry Garfield <larry@garfieldtech.com> wrote: > > Platform.sh, the managed host I work for, has offered every version of PHP since 7.1 day-of-release, and we also have a long list of available PECL extensions that can be enabled by adding a line to a YAML file. We also have a built-in build pipline where you can download and compile/install most other extensions as desired. We're also a Git-based host with every Git branch able to be a running environment. > > It's not that managed hosts can't make new-stuff easily available. It's that many don't. But enough do that if you need the latest-and-greatest, you have plenty of options.
It depends on who you are saying "has plenty of options." If you mean the person with the authority to make a decision on a platform, then you are correct. But if you mean the developer whose only option is to use the platform the decision maker choses, or has previous chosen, then option(s) sum to a total of one (1). ------- Listen, I am just trying to point out that not everyone gets to choose their web host nor do many get to choose their PHP extensions, and for those people having the PHP community choose to package functionality as a PHP/PECL extension causes those individuals to be "have nots" in the PHP world. So I am arguing for PHP-equality vs what we have now which is a two-level PHP caste system. -Mike
  109258
March 23, 2020 21:41 rowan.collins@gmail.com (Rowan Tommins)
On 23/03/2020 19:55, Mike Schinkel wrote:
>> As long as that's true, there will be hosts who disable features you wish >> they wouldn't. > Generally that is not the issue with WordPress. > > Most managed WordPress hosts support the required ones...
I wasn't saying they disable features you *need*, I said they disable features you *might want*. This is the part of my e-mail where I thought I was agreeing with you - having features optional means not everyone gets them (pretty much by definition). It sounds like there's a kind of evolved symbiosis in this case - a wide range of hosts support the optional features WordPress requires, and WordPress requires as few as possible because it aims to run on a wide range of hosts. I'm not sure ease of installation particularly factors into that, it's more about supply and demand.
>> Regarding choice of language for that mechanism, I'm not sure we need to >> look any further than PHP itself: what we're really talking about is making >> facilities available to the average user that are currently only available >> to extension developers. > If that is the case then we probably need to add more improvements to the PHP language than have been added in the past 10 years because there is so much you can't reasonably do in PHP. One example would be to adopt the gradual typing of Hack to allow for significant performance improvement.
I don't think that's the case for the kind of workload you're talking about elsewhere in this thread - that is, I don't think rewriting any part of WordPress in Rust would make much difference to people running sites on Pantheon. For specialist workloads, there may well be advantages to binding PHP with optimized native code; but those are likely to be running in self-managed environments, where traditional extensions, and now FFI, would be available anyway. When I talked about "making facilities available", I was thinking more about things that userland PHP simply can't do - special types of objects, manipulation of other parts of the language, hooks into the engine.
> It is notable you mention Zephir but make no mention to WASM, which is what I pointed to as the most promising extension mechanism I currently see on the horizon. > ... > But why no reference to WASM? WASM would let us write extensions in many languages. Even better, we could write a PHP-to-WASM compiler for a WASM-specific dialect of PHP.
To be honest, the reason I didn't talk about WASM is because I don't really understand how it fits into the conversation. My understanding is that WASM is a cross-platform target for code written in other languages, filling roughly the same role as JVM, .Net CLR, etc, but the underlying "OS" is web browsers. PHP's equivalent, at least in theory, is the Zend Engine. Running PHP code in the same runtime as other languages could be cool - that could mean compiling PHP to WASM, or to MoarVM (the current Raku/Perl6 target); or it could mean stabilising Zend OpCodes so we can compile JS to them. But I don't think that's what you were talking about. Could you clarify what kind of thing you think would benefit from having a WASM layer? Regards, -- Rowan Tommins (né Collins) [IMSoP]
  109271
March 24, 2020 13:49 thruska@cubiclesoft.com (Thomas Hruska)
On 3/23/2020 12:08 PM, Rowan Tommins wrote:
> On Mar 23, 2020, at 1:51 PM, Ben Ramsey <ben@benramsey.com> wrote: > Thank you, yes, that's exactly what I'm saying. PHP is, right now, a > modular product. > > some have to be painfully worked around (e.g. curl).
Not sure it's as painful as you've said: https://github.com/cubiclesoft/ultimate-web-scraper/blob/master/docs/emulate_curl.md On a side note, good PHP userland streams-based implementations are faster than the ext/curl extension. The ext/curl extension also doesn't emit as much useful debugging information. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/