On Mon, 23 Mar 2020 at 09:31, Mike Schinkel <m...@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]
