Re: Are PECL modules preferable?
| From: | Mike Schinkel | Date: | Mon, 23 Mar 2020 17:10:24 +0000 |
| Subject: | Re: Are PECL modules preferable? | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-109235@lists.php.net to get a copy of this message | ||
> 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