> On Sep 20, 2024, at 3:56 AM, Arvids Godjuks <[email protected]> wrote:
> I want to chip in here, since reading the thread lead me into a state of cognitive dissonance.
> I've been in PHP world for a long time, about 3 years shy of how old Wordpress is. When
> I'm reading "shared hosting" and "WASM" and knowing how managed hosting
> works, I have to ask: What type of la-la land is this conversation is taking place in?
See these lists above showing the required and recommended extensions for WordPress, Laravel and
Drupal where all(?) other CMS/frameworks have an equivalent list:
- https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions
<https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions>
- https://laravel.com/docs/11.x/deployment#server-requirements
<https://laravel.com/docs/11.x/deployment#server-requirements>
- https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions
<https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions>
Managed hosts that want to sell to users of a CMS or frameworks operate in the "la-la
land" you speak of.
> what managed hoster in their right mind and sanity will allow WASM to be enabled to bypass
> ____A L L _____ PHP security features and allow PHP code do anything it wants?
That is a false assertion. WASM cannot bypass all PHP security; it is by-nature sandboxed.
Yes, there are ways that a good C++ developer could get around that, but as part of this discussion
we have been discussing ways to avoid allowing that, such as potentially enabling WASM for PHP to
only allow using AssemblyScript, at least initially.
> On a shared hosting... I seriously want to know answer to this question, because I firmly
> believe there was zero risk and security assessment not only done, but it hasn't been even a
> twinkle in the eye.
>
> On VPS/Decicated you can run whatever you want, so you don't have the limitations.
Shared hosting vs. VPS/Dedicated is a false dichotomy.
There is also managed hosting – typically run in sandboxed containers — that specialize in
running specific CMS and/or frameworks.
> On other note - people have pointed out how big body of work it is. If you want to sponsor WASM
> development for PHP, I suggest Automatic open their wallet and put in 2-3 million $ a year for the
> next 5-10 years to PHPFoundation and find devs who are capable and willing to do this job. Honestly,
> I think you might find people to want to do that rather than lack of money being the cause of it.
Well, that is an option, and I would be glad to see it.
However, my guess is that Automattic (spelled correctly) is not likely to do that given how
dismissive PHP Internals and by extension the PHP Foundation has been regarding the needs of
WordPress users for as long as you Arvids have been doing PHP.
But who knows, maybe there could be a détente? Who on this list would be more open than in the
past to treat concerns of WordPress users as legitimate rather than dismiss them because (I am
paraphrasing) "how bad their code is?"
> On Sep 20, 2024, at 3:39 PM, Niels Dossche <[email protected]> wrote:
> Perhaps I'm missing something in this discussion, as this discussion has all sorts of
> tangents and is quite lengthy. Also easy to forget what's been said and not.
> Anyway, there is already a wasm extension for PHP: https://github.com/veewee/ext-wasm
The something you might be missing is the discussion is about potentially having WASM as a bundled
extension in PHP core rather than there just having one be available, and the reason is so that it
can become a viable option for CMS & Framework vendors to include on their list of required or
at least recommended extensions.
> On Sep 20, 2024, at 7:27 PM, Rowan Tommins [IMSoP] <[email protected]> wrote:
> It's absolutely possible to build a PHP extension that interfaces to a WASM runtime, and
> links have been shared to at least two projects doing just that. Adding that to the php-src repo
> doesn't change what that extension can do, it just marks it as "approved" in some
> slightly ill-defined way, and restricts it to having new releases only once per year.
>
> 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)
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.
I absolutely love that Larry called the question if it were technically possible. Maybe Larry will
read this and can answer the question — since he was heavily involved with Drupal — "Would
Drupal be willing to require or at least recommend a 3rd party WASM extension vs. a bundled one
here? https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions
<https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions>"
> At which point, some managed hosting servers might be more willing to install it. Not the ones
> who don't even install ext/curl, those are never going to benefit from this.
There are very few (if any) that won't install curl as you cannot run WordPress w/o curl. Your
knowledge of what hosting providers will and will not install seems to be rather dated.
> But maybe the ones who install a reasonable list of features, but are a bit wary of installing
> PECL extensions they don't know much about, can be persuaded to trust their users with a WASM
> sandbox.
Or the ones who want to target the users of the CMS or Framework that recommend or require the
extension.
If the extension were bundled then I expect it could become a recommended extension for hosts to
enable and WordPress could start shipping WASM extensions for the use-cases Dennis Snell mentioned
that can optionally run if the WASM extension is enabled vs. if not it would just run the old slower
PHP code.
BTW, Dennis, could you see WordPress recommending a WASM extension if PHP bundled one here? https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions
<https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions>
> On Sep 20, 2024, at 8:51 PM, Hammed Ajao <[email protected]> wrote:
> Ah so you want to make huge changes to the engine for even less users?
Why make such a leading yet false assertion?
The fact it can be implemented in an PHP extension discretions your assert that it would require
"huge changes to the engine." In fact, it would not require *any* changes to the engine.
> If you insist, I'll await your MVP.
Here it is: https://github.com/wasmerio/wasmer-php/releases/tag/1.1.0
> So maybe those companies should implement it themselves or pay to have it implemented.
Or maybe those companies just give up on using PHP rather than constantly deal with intransigence
among community members when improvements are even mentioned? Most of my work has been in Go lately,
motivated in large part because of PHP's governance model that centers around this list and the
hostile and non-constructive reactions that are far too common on this list.
> How would we handle the JS-like stdlib of assembly script? Another abstraction layer? That
> seems easier to you than a DSL created specifically for this?
You mischaracterize, but yes, an existing working WASM is easier IMO than a DSL that is just
"concepts of a plan."
(Those quotes were not yours, I am just making a pun on something that was said recently by someone
well-known in the USA.)
> With PHP like syntax?
Why is "PHP like syntax" a blocking requirement? C does not have a PHP-like syntax, or at
least one that is not more similar to AssemblyScript than PHP. Why then is C acceptable for
extensions but AssemblyScript is not?
And even so, there is no reason a PHP-like syntax is required. PHP developers work with JS or TS
every day, and AssemblyScript is just a variant of TypeScript.
> Using the parser already in the engine? With a PHP-like stdlib?
>
>
> > > In essence, WebAssembly is great for certain scenarios, but PHP has existing
> > > mechanisms that make the addition of a Wasm runtime potentially redundant for most use cases.
>
> Then for those cases where it is redundant, don't use it.
>
> That's most use cases. It doesn't make any sense to burden all users and contributors
> just so some companies can maybe decide to enable wasm to make more money.
First, it would not burden all users nor all contributors; that is an invalid claim I have
discredited above.
Second, that sounded like a Freudian slip where you said the quiet part out loud. Is this about you
somehow having a hot button about "some people wanting to make money" rather than
accepting people just want to be able to write better and faster websites in PHP? If "some
people wanting to make money" were the discrediting bar then (almost?) every feature request
could be denied on that basis.
> Honestly, a DSL would be the perfect solution here. Anyone familiar with writing PHP extensions
> knows about gen_stub.php, which scans PHP stubs and generates the corresponding binding
> C code.
When and where does the C code get compiled?
And isn't that what Zephir actually is?
> I've often thought this process could be extended to handle more complex scenarios like
> promoted properties, simple expressions (e.g., assignments, property access, comparisons), and
> anything that can be easily translated into C code.
>
> V8 has a similar tool called Torque, and I've always wondered what something like that
> would look like for PHP. It would result in a strict, statically typed subset of PHP that satisfies
> all the requirements, except for the last one (which it would only partially fulfill).
>
> Since the generated code would interface directly with the Zend API, we can consider the DSL
> code as safe as the PHP implementation itself. While there wouldn't be CPU throttling, hosts
> shouldn't have major objections since it would essentially be as safe as PHP.
>
> Most importantly, this approach would benefit everyone. It would have no third-party
> dependencies and would only need to evolve alongside PHP/Zend as they grow.
>
> That’s how I would approach it.
I await your proposal. Sincerely.
And I don't mean to the level of an RFC, but a document that details how it would work, and one
that could be discussed and commented on as you can on a Github repo.
Note I am not advocating fro a *specific* approach — e.g. WASM — I am advocated to achieved the
stated goal, e.g. an extension mechanism that can run at near native speed for low-level string
parsing and maths that realistically will be able to be run on managed hosts which IMO means they
have to be adopted by major CMS and/or Frameworks as requirements if not at least recommendations.
If your ideas can achieve those goals, I would fully be behind them. (I am however skeptical that
what you proposal can achieve all those goals; prove me wrong.)
> On Sep 20, 2024, at 4:18 AM, Rowan Tommins [IMSoP] <[email protected]> wrote:
> On 20 September 2024 06:20:46 BST, Mike Schinkel <[email protected]> wrote:
>> Moot point as it cannot be run on a managed hosted server.
>
> Why not? Only because the people managing that server haven't been persuaded to include it
> as an option. And that is mostly because it's currently experimental, and there isn't wide
> demand for it.
You can hypothetical all day long, but the reality is that if something is not shipped with PHP,
someone wanting to write PHP code that a library, CMS or frameworks depends on would have to play a
failure-guaranteed game of whack-a-mole to get a lot of managed hosting providers to support it.
And the larger CMS and frameworks are rightly not going to support something that does not get
bundled into php-src.
>>> Just to reiterate, if by "built-in to PHP core", you mean "every copy of
>>> PHP includes a functional WASM runtime", that's not going to happen. It would mean
>>> bundling (or requiring every user to install) a huge third-party dependency, with all of its
>>> dependencies and platform requirements, even if they weren't interested in using it.
>>
>> So why do you claim that bundling a third-party dependency is a "never going to
>> happen" scenario?
>>
>> By that logic PHP would have none of these functionalities:
>>
>> • cURL
>> • GD
>> • PDO
>> • OpenSSL
>> • MBString
>> • Zlib
>> • Zip
>> • XSL
>> • EXIF
>> • BCMath
>
> None of those are "built into PHP core" in the sense of "every copy of PHP
> includes them". Nor do any of them bundle their third-party dependencies.They are all optional
> extensions, which the user has to provide the dependencies for if they want to install and enable
> them.
Fine, we can treat WASM the same as all those other extensions and bundling it with PHP meaning
;extension=wasm line in production.ini, the internal code needed to link in the
library, and compiler switches to compile it in.
If PHP were to ship in this way then CMS and Frameworks could choose to add WASM to their list of
required or recommended extensions, as it sounds like from Dennis Snell's really excellent
messages that WordPress would likely want to do that:
- https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions
<https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions>
- https://laravel.com/docs/11.x/deployment#server-requirements
<https://laravel.com/docs/11.x/deployment#server-requirements>
- https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions
<https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#extensions>
Once CMS & Frameworks are empowered to use WASM as part of their core offering then they could
start recommending WASM and managed web hosts that want to cater to their users would start offering
WASM enabled on their platforms.
BTW, very few CMS or Frameworks make any extensions not referenced in production.ini as
requirements, and for very good reason because doing so would be too risky.
> They are what is sometimes referred to as "bundled extensions", which just means they
> have source code in the php-src repository, and get new releases at the same time as PHP. Being in
> that list doesn't mean managed hosts have to provide them (who would force them?) and not being
> in that list doesn't mean managed hosts can't provide them (it's as easy to install
> "php-mongodb" on Ubuntu as "php-mysqli", even though one is "bundled"
> and the other hosted on PECL).
>
> Being "bundled" may be interpreted as something of a "stamp of approval",
> indicating that an extension is mainstream and stable. That's something that has to be earned -
> many extensions started out in their own projects, with releases listed on PECL or elsewhere, and
> were proposed for adoption into the php-src repo once they became stable.
>
> Which is why I say your energies for now are best spent on a project like extism, or wasmer-php
> - build that stable extension, and then we can discuss whether it would be beneficial to adopt it
> into the php-src repo.
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.
That would be much more productive than debating hypotheticals.
-Mike