[PHP-DEV] Zephir, and other tangents

Mailing Lists php.internals
21

On Tue, Sep 17, 2024 at 8:30 PM Dennis Snell <dennis.snell@automattic.com> wrote:

On Sep 17, 2024, at 2:03 PM, Rob Landers rob@bottled.codes wrote:

On Tue, Sep 17, 2024, at 14:57, Adam Zielinski wrote:

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on

shared hosts for things that are just not possible in PHP as described a

few paragraphs prior, and where we could enhance functionality over time,

  1. Constantly improving PHP the language, which is what you are solely

advocating for over extensibility,

Hi Mike,

I’m Adam, I’m building WordPress Playground [1] – it’s WordPress running in the browser via a WebAssembly PHP build [2]. I’m excited to see this discussion and wanted to offer my perspective.

WebAssembly support in PHP core would be a huge security and productivity improvement for the PHP and WordPress communities.

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on

shared hosts for things that are just not possible in PHP as described a

few paragraphs prior, and where we could enhance functionality over time,

Exactly this! With WASM, WordPress would get access to fast, safe, and battle-tested libraries.

Today, we’re recreating a lot of existing libraries just to be able to use them in PHP, e.g. parsers for HTML [3], XML [4], Zip [5], MySQL [6], or an HTTP client [7]. There are just no viable alternatives. Viable, as in working on all webhosts, having stellar compliance with each format’s specification, supporting stream parsing, and having low footprint. For example, the curl PHP extensions is brilliant, but it’s unavailable on many webhosts.

With WebAssembly support, we could stop rewriting and start leaning on the popular C, Rust, etc. libraries instead. Who knows, maybe we could even polyfill the missing PHP extensions?

  1. Constantly improving PHP the language, which is what you are solely

advocating for over extensibility,

Just to add to that – I think WASM support is important for PHP to stay relevant. There’s an exponential advantage to building a library once and reusing it across the language boundaries. A lot of companies is invested in PHP and that won’t change in a day. However, lacking access to the WASM ecosystem, I can easily imagine the ecosystem slowly gravitating towards JavaScript, Python, Go, Rust, and other WASM-enabled languages.

Security-wise, WebAssembly is Sandboxed and would enable safe processing of untrusted files. Vulnerabilities like Zip slip [8] wouldn’t affect a sandboxed filesystem. Perhaps we could even create a secure enclave for running composer packages and WordPress plugins without having to fully trust them.

Another use-case is code reuse between JavaScript and PHP. I’m sceptical this could work with reasonable speed and resource consumption, but let’s assume for a moment there is a ultra low overhead JavaScript runtime in WebAssembly. WordPress could have a consistent templating language. PHP backend would render the website markup using the same templates and libraries as the JavaScript frontend. Half the code would achieve the same task.

Also, here’s a few interesting “WASM in PHP” projects I found – maybe they would be helpful:

[1] https://github.com/WordPress/wordpress-playground/

[2] https://github.com/WordPress/wordpress-playground/tree/trunk/packages/php-wasm/compile

[3] https://developer.wordpress.org/reference/classes/wp_html_processor/

[4] https://github.com/WordPress/wordpress-develop/pull/6713

[5] https://github.com/WordPress/blueprints-library/blob/87afea1f9a244062a14aeff3949aae054bf74b70/src/WordPress/Zip/ZipStreamReader.php

[6] https://github.com/WordPress/sqlite-database-integration/pull/157

[7] https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPress/AsyncHttp/Client.php

[8] https://security.snyk.io/research/zip-slip-vulnerability

-Adam

Hey Adam,

I actually went down something like this road for a bit when working at Automattic. My repo even probably still exists in the graveyard repository… but I had plugins running in C# and Java over a couple of weeks. This was long before wasm was a thing, and while cool, nobody really could think of a use for it.

It seems like you have a use for it though, and I’m reasonably certain you could get it working over ffi in a few weeks; yet you mention hosts not even having the curl extension installed, so I doubt that even if wasm came to be, it would be available on those hosts.

There are two major areas I have found that would benefit from having a WASM runtime in PHP:

Obviously, being able to run the same algorithms on the frontend and backend is a huge win for consistency in applications.

I’m not convinced. That’s what they said about nodejs(same algos and same language on FE and BE). Except it’s not really that consistent because there are several discrepancies between the browser and node runtime. I’ll believe it when I see it.

Particularly with text-related algorithms it’s really easy for inconsistencies to develop due to the features available in each languages standard library, as well as due to differences in how each language handles and processes string.

I can see the appeal of that though.

The other major area is similar, and we’ve seen this with the HTML and XML parsing work recently undertaken in WordPress.

Yeah you could talk about html parsing before 8.4 but with 8.4 we get lexbor (thanks to niels) and that’s as good as it gets. Php already has beautiful support for XML though so I’m not sure why you would implement a parser yourself.

There are plenty of cases where efficient and spec-compliant operations are valuable, but these kinds of things tend to cost significantly more in user-space PHP.

Being able to jump into WASM, even with the overhead of exchanging that data and running another VM, would very likely result in a noticeable net improvement in runtime performance.

What exactly do you mean by jump into wasm? Like hand write it? Or you mean jump into a language that can be compiled to wasm? How about debugging at runtime? And if you mean better performance than PHP, while that is likely, it isn’t guaranteed. PHP is pretty fast and will be faster for some routines that are optimized by the engine. Wasm will never be as fast as extensions though because with extensions, all you’re doing is extending the engine. Same as any internal extension. With wasm you’re interoperating with an entirely separate VM.

Additionally, it’s a perk being able to write such algorithms in languages that aid that development through more powerful type systems.

We can agree on that. But I use C++ for my extensions so there’s also that.

There’s additional value in a number of other separate tasks. Converting images or generating thumbnails is a good example where raw performance is less of a concern than being able to ensure that the image library is available and not exposing the host system to risk.

Imo this is where FFI should shine but I’ll admit that the current implementation is lacking in both security and functionality.

I imagine plenty of “PHP lite-extensions” appearing in this space because it would give people the opportunity to experiment with features that are impractical in user-space PHP before fully committing the language itself to that interface or library. It would extend the reach of PHP’s usability because it would make possible for folks, who happen to be running on cheap shared hosts, to run more complicated processing tasks than are practical today. While big software shops and SaaS vendors do and can run their own custom PHP extensions, there’s not great way to share those generally to people without the same full control over their stack.

Shared hosting for php gets you the worst possible version of php. Can’t recompile to enable any bundled extension, can’t install any new extensions, so how exactly would you approach this? Wasm bundled with the engine by default? Or some kind of opt in mechanism that shared hosters won’t even be able to use?

However, plugins basically work via hooks/filters. So as long as you register the right listeners and handle serialization properly, you can simply run a separate process for the plugin, or call a socket for “remote” plugins.

I don’t see anything stopping anyone from implementing that today.

— Rob

I’m excited to see this conversation. I’ve wanted to propose it a number of times myself.

Warmly,
Dennis Snell

I actually love wasm, I’m currently in the process of compiling my mini php runtime to wasm (basically a browser only version of 3v4l). I’m not against this for any personal reasons, I’m simply not sure it’s the right approach.

Cheers,
Hammed

22

On Sep 19, 2024, at 12:00 PM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:

On Wed, 18 Sep 2024, at 20:33, Mike Schinkel wrote:

Yeah. That was the original goal.

But to say WASM's domain is limited to browsers is not valid any longer:
[...]

While it's definitely interesting seeing what uses it's being put to beyond the browser, the majority of those articles are talking about using WASM on its own, in the kind of places where you might use a container, to host things like microservices, serverless functions, etc.

Sigh. I did not include all potential examples. Leave it to you to limit your characterizations to only the ones I included.

Here is another:

Embedding it into other languages is a different usage again. It's certainly something that is being explored, e.g. by Extism, and that seems like a good project for anyone interested here to participate in, e.g. to help design the "glue" between PHP and WASM / Extism.

Moot point as it cannot be run on a managed hosted server.

WASM's ability to run on a managed server – assuming it were built-in
to PHP core

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

And PHP would be much less useful without any one of them.

The only runtimes where WASM is ever going to be available "out of the box" are those already built on a JavaScript engine (usually V8), like node.js, Deno, Electron, etc. The WASM is then running inside the existing runtime, not a whole new VM - like running Scala and Java code in the same JVM; or Hack and PHP in (older versions of) HHVM.

Seems you do not actually understand WASM runtimes.

While WebAssembly is available "out of the box" in JavaScript-based runtimes like Node.js, Deno, and Electron, it is not limited to them. Standalone WebAssembly runtimes like Wasmtime and WAVM allow WebAssembly to be run as a general-purpose compute target, outside the scope of a JavaScript engine.

On Sep 19, 2024, at 4:41 PM, Hammed Ajao <hamiegold@gmail.com> wrote:

Shared hosting for php gets you the worst possible version of php. Can't recompile to enable any bundled extension, can't install any new extensions, so how exactly would you approach this? Wasm bundled with the engine by default? Or some kind of opt in mechanism that shared hosters won't even be able to use?

To be clear, shared hosting and managed hosting can be VERY different animals.

I am advocating for enterprise-level managed hosting — like Pantheon — not shared hosting like GoDaddy.

On Sep 19, 2024, at 4:12 PM, Hammed Ajao <hamiegold@gmail.com> wrote:
On Wed, Sep 18, 2024, 1:33 p.m. Mike Schinkel <mike@newclarity.net> wrote:
But to say WASM's domain is limited to browsers is not valid any longer:

I don't know where you got that since I never said anything along those lines.

You did not say that explicitly, but you strongly implied it. Had you not meant to imply it then you'll argument would have made little sense because you would been implicitly admitting there are other uses for it.

But since you have all those guides and it's so practical, what's stopping you? You'd do a better job of convincing me with a MVP than some random blog posts.

Here you go:

BTW, as you being a C++ developer your argument is rather cynical because most PHP developers do not have the skills to write PHP extensions or work with FFI, and it is not a skill that can be acquired in a few weeks worth of free time. So you saying "Just do it" can be seen by a cynical person as you attempting to shut down discussion by presenting a blocking task that you can be pretty sure is too high a technical bar for most PHP developers.

I do want to gain that skill, but I doubt that I will be able to any time in the near future, especially not with other work commitments.

- Wasm workloads (Beta) | Docker Docs

You mean the feature that's been in beta since 2022? Yeah that's exactly what I'm referring to. If docker and all their money and engineers haven't shipped wasm in 2 years, how long do you think it'll take a bunch of volunteers?

Shipping as a container runtime without the surrounding support of a host is a bit more complicated than implementing within a host.

By your argument Node, Deno, and Wasmer would not have been able to ship WASM support yet.

You can't do shit on a managed server, that is not the bar at all.

Who made you the arbiter of what the bar should be for the needs of other people?

What makes you so sure that wasm will be allowed on managed hosts? What's the incentive for providers to allow it?

The incentives would be market differentiation and customer demand.

For security reasons it does not matter if customers demanded FFI or extensions written in C, there is simply too much risk.

But if there were a sandboxed secure runtime shipped with PHP, especially one that could be memory-limited and CPU-throttled, then it would be easy for some managed hosts to decide to enable it. Not all would, but channeling your imagined role as arbiter, I would say that is not "the bar."

> Extensions, which are already implemented in lower-level languages like C or C++, would still need to be compiled to WebAssembly if the goal were full compatibility.

When did I or anyone proposing WASM for PHP suggest that making compiling extensions into WebAssembly would necessarily be a blocking requirement?

This might lead us down the path of either creating a domain-specific language (DSL) for PHP—similar to AssemblyScript—or simply leaving it up to the library authors to choose lower-level languages (as is currently the case).

Or, simply allowing AssemblyScript as the initial way to use WASM in PHP core.

> 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.

I hear you, you want to run low level code on managed servers. I would approach the problem differently e.g. Creating some kind of directory for `trusted` php extensions, the criteria for what qualifies as `trusted` would be up for discussion. Or maybe we can bundle a small std lib of select extensions with core. Those make a lot more sense to me than adding an entire abstraction layer.

Many hosts already whitelist php extensions. That does not help.

The use-case being discussed by me and the others who commented in support of WASM is primarily bespoke code written for project-specific requirements.

I am not saying WASM has to be the thing to meets that need, but AFAIK there is no other potential similar solution that could address it. You can dismiss that goals as being unimportant or "not making sense," but that does not mean there are not those who find meeting that need to make a lot of sense.

Let me turn it around then and ask that — rather than being the gatekeeper against a solution— you instead propose a solution to address all the following requirements:

Ability to run some form of module/add-in/extension/whatever-you-want-to-call-it in PHP that:

1. Ships with PHP code so those managed hosts who want to enable it can easily do so,
2. Allows for fully-bespoke project-specific things to be developed,
3. Is reasonably easy to program in a secure way (not C or C++),
4. Enables near native performance for things like looping and string manipulation and maths, and
5. And is secure, can limit memory use, and can throttle CPU hogging so hosts will not object to enabling it.

Since you have already dismissed WASM as not the right approach, how would you alternately address those requirements?

-Mike

23

Hi Hammed, thank you for taking the time to read through this and share your thoughts.

On Sep 19, 2024, at 1:41 PM, Hammed Ajao hamiegold@gmail.com wrote:

On Tue, Sep 17, 2024 at 8:30 PM Dennis Snell <dennis.snell@automattic.com> wrote:

On Sep 17, 2024, at 2:03 PM, Rob Landers rob@bottled.codes wrote:

On Tue, Sep 17, 2024, at 14:57, Adam Zielinski wrote:

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on

shared hosts for things that are just not possible in PHP as described a

few paragraphs prior, and where we could enhance functionality over time,

  1. Constantly improving PHP the language, which is what you are solely

advocating for over extensibility,

Hi Mike,

I’m Adam, I’m building WordPress Playground [1] – it’s WordPress running in the browser via a WebAssembly PHP build [2]. I’m excited to see this discussion and wanted to offer my perspective.

WebAssembly support in PHP core would be a huge security and productivity improvement for the PHP and WordPress communities.

To summarize, I think PHP would benefit from:

  1. Adding WASM for simple low-level extensibility that could run on

shared hosts for things that are just not possible in PHP as described a

few paragraphs prior, and where we could enhance functionality over time,

Exactly this! With WASM, WordPress would get access to fast, safe, and battle-tested libraries.

Today, we’re recreating a lot of existing libraries just to be able to use them in PHP, e.g. parsers for HTML [3], XML [4], Zip [5], MySQL [6], or an HTTP client [7]. There are just no viable alternatives. Viable, as in working on all webhosts, having stellar compliance with each format’s specification, supporting stream parsing, and having low footprint. For example, the curl PHP extensions is brilliant, but it’s unavailable on many webhosts.

With WebAssembly support, we could stop rewriting and start leaning on the popular C, Rust, etc. libraries instead. Who knows, maybe we could even polyfill the missing PHP extensions?

  1. Constantly improving PHP the language, which is what you are solely

advocating for over extensibility,

Just to add to that – I think WASM support is important for PHP to stay relevant. There’s an exponential advantage to building a library once and reusing it across the language boundaries. A lot of companies is invested in PHP and that won’t change in a day. However, lacking access to the WASM ecosystem, I can easily imagine the ecosystem slowly gravitating towards JavaScript, Python, Go, Rust, and other WASM-enabled languages.

Security-wise, WebAssembly is Sandboxed and would enable safe processing of untrusted files. Vulnerabilities like Zip slip [8] wouldn’t affect a sandboxed filesystem. Perhaps we could even create a secure enclave for running composer packages and WordPress plugins without having to fully trust them.

Another use-case is code reuse between JavaScript and PHP. I’m sceptical this could work with reasonable speed and resource consumption, but let’s assume for a moment there is a ultra low overhead JavaScript runtime in WebAssembly. WordPress could have a consistent templating language. PHP backend would render the website markup using the same templates and libraries as the JavaScript frontend. Half the code would achieve the same task.

Also, here’s a few interesting “WASM in PHP” projects I found – maybe they would be helpful:

[1] https://github.com/WordPress/wordpress-playground/

[2] https://github.com/WordPress/wordpress-playground/tree/trunk/packages/php-wasm/compile

[3] https://developer.wordpress.org/reference/classes/wp_html_processor/

[4] https://github.com/WordPress/wordpress-develop/pull/6713

[5] https://github.com/WordPress/blueprints-library/blob/87afea1f9a244062a14aeff3949aae054bf74b70/src/WordPress/Zip/ZipStreamReader.php

[6] https://github.com/WordPress/sqlite-database-integration/pull/157

[7] https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPress/AsyncHttp/Client.php

[8] https://security.snyk.io/research/zip-slip-vulnerability

-Adam

Hey Adam,

I actually went down something like this road for a bit when working at Automattic. My repo even probably still exists in the graveyard repository… but I had plugins running in C# and Java over a couple of weeks. This was long before wasm was a thing, and while cool, nobody really could think of a use for it.

It seems like you have a use for it though, and I’m reasonably certain you could get it working over ffi in a few weeks; yet you mention hosts not even having the curl extension installed, so I doubt that even if wasm came to be, it would be available on those hosts.

There are two major areas I have found that would benefit from having a WASM runtime in PHP:

Obviously, being able to run the same algorithms on the frontend and backend is a huge win for consistency in applications.

I’m not convinced. That’s what they said about nodejs(same algos and same language on FE and BE). Except it’s not really that consistent because there are several discrepancies between the browser and node runtime. I’ll believe it when I see it.

There’s a note about this point that I think is worth calling out, and that is something you probably already know, but JavaScript runtimes provide a standard library while a WASM runtime is mostly just a virtual machine. There’s also nothing provided that I’m aware of in WASM that offers filesystem access or network access, which are major areas where in-browser JavaScript and NodeJS backends differ (because the browser and server environments are fundamentally limited by different needs).

As things stand, projects are compiled into WebAssembly and literally run identically in the different runtimes because it’s the bytecode that’s specified, not specific functions or libraries. Whereas with JavaScript we’re shipping source code and interacting with very different systems, WASM bundles are a few steps removed from that, and have no DOM or system access to interact with.

I’m fairly confident we can say that it’s non-controversial that folks routinely run identical algorithms across different WASM runtimes in different environments. As you mentioned elsewhere, it’s very much akin to how Java and Closure and Scala all run on the JVM just fine together even being different languages, except in this case the runtime is an isolated sandbox by default with no external system access. WASM is a lovely little VM, successful in ways many before it haven’t been.

Particularly with text-related algorithms it’s really easy for inconsistencies to develop due to the features available in each languages standard library, as well as due to differences in how each language handles and processes string.

I can see the appeal of that though.

The other major area is similar, and we’ve seen this with the HTML and XML parsing work recently undertaken in WordPress.

Yeah you could talk about html parsing before 8.4 but with 8.4 we get lexbor (thanks to niels) and that’s as good as it gets. Php already has beautiful support for XML though so I’m not sure why you would implement a parser yourself.

It’s wonderful that PHP is finally getting a spec-compliant HTML DOM parser for the first time in its history, but \Dom\HTMLDocument is not the right interface for every server need, and remains ill-suited for the kind of work typical in a WordPress site, which needs to run on low memory budgets, perform as fast as possible, and exceed the safety of what a generic DOM parser produces (there are cases that \Dom\HTMLDocument will still introduce vulnerabilities into an HTML document because it’s able to create DOM trees that cannot be represented by HTML upon serialization, and as it implements the HTML spec, it cannot prevent creating those trees). There are still a number of steps every developer needs to take to properly setup the parser and get the right results back, and the parser has to load the entire DOM tree into memory before any reads or manipulations can be performed on it.

WordPress’ HTML API is a near-zero memory overhead streaming HTML parser designed around safe-by-default reading and writing of HTML which requires no configuration or manual steps to get “the right thing.” It’s also significantly slower in user-space PHP than it needs to be. I hope one day that PHP has its own copy of this streaming parser design, which is performant and available in every copy of PHP (which is another issue with code only available in extensions), but even if that never happens, running C or Rust code compiled to WebAssembly would provide almost the same value as having that design implemented in the language.

There are plenty of cases where efficient and spec-compliant operations are valuable, but these kinds of things tend to cost significantly more in user-space PHP.

Being able to jump into WASM, even with the overhead of exchanging that data and running another VM, would very likely result in a noticeable net improvement in runtime performance.

What exactly do you mean by jump into wasm? Like hand write it? Or you mean jump into a language that can be compiled to wasm? How about debugging at runtime? And if you mean better performance than PHP, while that is likely, it isn’t guaranteed. PHP is pretty fast and will be faster for some routines that are optimized by the engine. Wasm will never be as fast as extensions though because with extensions, all you’re doing is extending the engine. Same as any internal extension. With wasm you’re interoperating with an entirely separate VM.

By jumping into WASM I’m talking about the second thing you mention: calling functions written in languages compiled to WebAssembly. Even with the overhead of marshaling data, the things that WebAssembly is good at are the things that PHP is slow at: specifically things like raw numeric computation and string manipulation and parsing. I write a lot of parsing code and frequently am surprised at the overhead cost of string processing and array operations in PHP. There are a number of straightforward operations available in C that just can’t be done in PHP. I don’t see this as a failing of PHP, just an aspect of how it is.

For runtime debugging I don’t have any particular thoughts. I’m not aware of anyone who has ever tried to runtime debug CURL calls or things like mb_convert_encoding(). Functions invoked in the WASM runtime would more or less be library functions, like ffmpeg. Debugging would likely most frequently be done as a library and dumped into the PHP application with no expectation for debugging.

Effectively these are user-space PHP extensions, and are very convenient because they can be updated without recompiling PHP or begging web hosts to update their PHP version, or to do that every other Tuesday, or whenever another security exploit is fixed in some image processor. On that note, the ability to sandbox image processing code (and any other user-provided content) is a huge perk. Many of the exploits of past PHP extensions could be contained inside the VM, which has limited ability to reach out into the system. Fixing vulnerabilities and bugs becomes something any auto-updater can accomplish, requiring no effort or interaction on the part of the host.

Additionally, it’s a perk being able to write such algorithms in languages that aid that development through more powerful type systems.

We can agree on that. But I use C++ for my extensions so there’s also that.

There’s additional value in a number of other separate tasks. Converting images or generating thumbnails is a good example where raw performance is less of a concern than being able to ensure that the image library is available and not exposing the host system to risk.

Imo this is where FFI should shine but I’ll admit that the current implementation is lacking in both security and functionality.

I imagine plenty of “PHP lite-extensions” appearing in this space because it would give people the opportunity to experiment with features that are impractical in user-space PHP before fully committing the language itself to that interface or library. It would extend the reach of PHP’s usability because it would make possible for folks, who happen to be running on cheap shared hosts, to run more complicated processing tasks than are practical today. While big software shops and SaaS vendors do and can run their own custom PHP extensions, there’s not great way to share those generally to people without the same full control over their stack.

Shared hosting for php gets you the worst possible version of php.

Couldn’t have said it better myself!

Can’t recompile to enable any bundled extension, can’t install any new extensions, so how exactly would you approach this? Wasm bundled with the engine by default? Or some kind of opt in mechanism that shared hosters won’t even be able to use?

As with many of the things I’ve been writing on this list lately, to me, an embedded WASM runtime makes most sense as a central language feature and available everywhere PHP is deployed. There are a few core basic subsystems that either are foundational to the environment PHP operates in (for example, web-related technologies like HTTP and HTML and URLs) or which bring so much value to the language that it opens up brand new paradigms or potentially removes major maintenance burdens.

If we could ship imagemagick as a WASM extension there would be no need for the imagemagick extension. The security environment out of the box is so much better; it’s not worth the lost potential for performance that a native extension offers. Someone may not agree with this, and that’s fine because they can always install a native extension or utilize the FFI on infrastructure they control.

I think at times WordPress sees a very different picture of the world than many great PHP projects see. Our reality is that we’re writing code that runs on hardware we don’t control or even know about. We cannot in any way install or force certain extensions to be present. The worst possible version of PHP is literally the constraint at which we are allowed to code. Anything beyond that and we can’t ship it because a large fraction of the internet will start crashing. It’s frustrating, but also an honor to be able to ensure that people who can’t afford high end servers can still build their own place on the world wide web.

Over the past several years, though, WordPress has also been a positive influence on persuading hosts to update their PHP versions, because PHP has gotten better enough that the argument is easy: upgrade to PHP 7 and your data center costs will drop X%. It’s not too hard to imagine winning similarly on the security argument.

WASM code on memory-constrained, oversubscribed, CPU-poor hosts is still considerably better for certain kinds of computation than user-space PHP code on memory-constrained, oversubscribed, CPU-poor hosts.

However, plugins basically work via hooks/filters. So as long as you register the right listeners and handle serialization properly, you can simply run a separate process for the plugin, or call a socket for “remote” plugins.

I don’t see anything stopping anyone from implementing that today.

— Rob

I’m excited to see this conversation. I’ve wanted to propose it a number of times myself.

Warmly,
Dennis Snell

I actually love wasm, I’m currently in the process of compiling my mini php runtime to wasm (basically a browser only version of 3v4l). I’m not against this for any personal reasons, I’m simply not sure it’s the right approach.

That sounds awesome. The WordPress Playground ships a copy of PHP compiled to WASM, and it’s been an incredible journey realizing just what’s capable with this technology. It’s really boosted the developer experience working on WordPress itself and also that of those building their own projects using WordPress. Some are already bringing in libraries like ffmpeg to convert images and media on the frontend, though it’s sad that can’t also be done on the server yet.

Cheers,
Hammed

Hope you have a nice weekend. Cheers.

24

Hello everyone,

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?
All managed wordpess hosting is locked down hard. Extensions are very limited and everything that allows any type of freedom is disabled, functions are disabled en mass. I have to ask: knowing the history of past 27 years, 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? 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.

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.

···

Arvīds Godjuks+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

25

On 20 September 2024 06:20:46 BST, Mike Schinkel <mike@newclarity.net> wrote:

Embedding it into other languages is a different usage again. It's certainly something that is being explored, e.g. by Extism, and that seems like a good project for anyone interested here to participate in, e.g. to help design the "glue" between PHP and WASM / Extism.

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.

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.

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.

Seems you do not actually understand WASM runtimes.

While WebAssembly is available "out of the box" in JavaScript-based runtimes like Node.js, Deno, and Electron, it is not limited to them. Standalone WebAssembly runtimes like Wasmtime and WAVM allow WebAssembly to be run as a general-purpose compute target, outside the scope of a JavaScript engine.

I absolutely understand that; I already said that it will be interesting to see how projects like extism develop, making use of those runtimes to run alongside other languages. But as far as PHP, or Python, or Java, is concerned, those runtimes are an external process or library that is being interfaced. Integrating with them is no different, in principle, from integrating the driver for some new kind of database.

Which is great; it means you don't need any approval from this list, or to write up an RFC, you can get involved in building that integration right now, wherever people are working on an extension to enable it.

Regards,
Rowan Tommins
[IMSoP]

26

Personally, for me, wasm becomes very interesting when we have dedicated CPU architectures that handle the wasm op codes natively in server farms. Otherwise, wasm is nice for mix-and-match language use or cleaning up systems with poor memory handling but not super-critical. Just my own personal opinion. --Kent

27

Hi Hammed, thank you for taking the time to read through this and share your thoughts.

snip

Cheers,
Hammed

Hope you have a nice weekend. Cheers.

Hello everyone,

I want to chip in here, since reading the thread lead me into a state of cognitive dissonance.

Hi Arvīds, that sounds stressful. This is definitely a wavering thread, as noted by the “tangents” subject. As far as the email you’re replying to, the main point is that if PHP offered a way to embed safe native-like extensions in a sandbox, then lots of the pressure to add and maintain extensions would drop from the host and provider and enable the customers to manage that on their own, and open many doors for PHP. A WASM runtime engine inside PHP would be a viable path to get to that point.

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?
All managed wordpess hosting is locked down hard. Extensions are very limited and everything that allows any type of freedom is disabled, functions are disabled en mass. I have to ask: knowing the history of past 27 years, 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? 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.

These are good questions. The basic point of confusion might stem from what the security domain is for a WASM runtime. It’s actually precisely because of the concerns you raise that WASM is a candidate here, being sandboxed by default and unable to interact with the host system.

That is, a WASM extension not only can’t bypass any PHP security features, but it’s significantly more constrained than any PHP code is. Managed hosts are locked down largely because of the security concerns that are categorically not present with the system we’re discussing, so being able to offer more on their platforms without having to dedicate additional resources to it could be a nice selling point.

On VPS/Decicated you can run whatever you want, so you don’t have the limitations.

I mentioned this in my email; I appreciate that many folks around here have full control over their infrastructure, but when building platform like WordPress or any of the other PHP frameworks, we just don’t have the liberty of having that control. In any case, even some very large shops who write and manage their own PHP extensions are constantly on the hook for security issues and updates and breakages. I’m sure we’d do much more at Automattic to extend PHP if we could do so without the security, platform-dependancy, and build issues involved in maintaining custom extensions.

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.

I’m not sure why you’re singling out Automattic, since nobody from Automattic started this thread or requested other people provide unfunded volunteer work, or why you’re expecting a single corporate entity to fully fund long-term planned features in the language. Is that how PHP normally grows? I’m not familiar with the process.

My goal in sharing here is to help better represent my own perspective of WordPress’ needs based on what I’ve seen. It’s long been on my list to propose a WASM RFC, but because I personally haven’t had the priority available to get an implementation working I haven’t done so. It’s my impression from the documentation that the purpose of these email threads w.r.t. RFCs is to gather interest and input before any RFC would be put together, to hold these discussions before anyone commits any major time to it.

–

Warmly,
Dennis Snell

···

Arvīds Godjuks+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

28

On Fri, Sep 20, 2024, at 12:28 PM, Dennis Snell wrote:

I’m not sure why you’re singling out Automattic, since nobody from
Automattic started this thread or requested other people provide
unfunded volunteer work, or why you’re expecting a single corporate
entity to fully fund long-term planned features in the language. Is
that how PHP normally grows? I’m not familiar with the process.

My goal in sharing here is to help better represent my own perspective
of WordPress’ needs based on what I’ve seen. It’s long been on my list
to propose a WASM RFC, but because I personally haven’t had the
priority available to get an implementation working I haven’t done so.
It’s my impression from the documentation that the purpose of these
email threads w.r.t. RFCs is to gather interest and input before any
RFC would be put together, to hold these discussions before anyone
commits any major time to it.

FWIW, I feel that an embedded Wasm bridge, with a good API, would be an excellent addition and way more useful than the crappy experience of FFI.

Logistical question, for those with more stdlib expertise: Since we have other extensions in php-src that only work if you install some other library as well (eg, curl), which distros pretty much take care of for us, would a small in-php-src extension that is just a thin wrapper for Wasmtime or similar be viable? Not embedding Wasmtime into the php-src code, just the extension, and it's up to the user/distro to install both so that they work.

(Note: I'm not asking if you think it's a good idea, just if it's physically possible/worth discussing.)

--Larry Garfield

29

FWIW, I feel that an embedded Wasm bridge, with a good API, would be an excellent addition and way more useful than the crappy experience of FFI.

:confused_face:

Logistical question, for those with more stdlib expertise: Since we have other extensions in php-src that only work if you install some other library as well (eg, curl), which distros pretty much take care of for us, would a small in-php-src extension that is just a thin wrapper for Wasmtime or similar be viable? Not embedding Wasmtime into the php-src code, just the extension, and it's up to the user/distro to install both so that they work.

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: GitHub - veewee/ext-wasm: Run webassembly from PHP

Kind regards
Niels

30

Hi,

On Fri, Sep 20, 2024 at 6:32 PM Dennis Snell <dennis.snell@automattic.com> wrote:

My goal in sharing here is to help better represent my own perspective of WordPress’ needs based on what I’ve seen. It’s long been on my list to propose a WASM RFC, but because I personally haven’t had the priority available to get an implementation working I haven’t done so. It’s my impression from the documentation that the purpose of these email threads w.r.t. RFCs is to gather interest and input before any RFC would be put together, to hold these discussions before anyone commits any major time to it.

Is your objective to support building PHP to wasm32-wasi target like it was proposed here: https://github.com/php/php-src/pull/10457 ? If so, the main issue with that was inability to do the zend_bailout as wasm does not support currently support setjmp and longjmp. Otherwise it’s mostly about disabling some functionality.

Regards

Jakub

31

On Sep 20, 2024, at 1:21 PM, Jakub Zelenka bukka@php.net wrote:

Hi,

On Fri, Sep 20, 2024 at 6:32 PM Dennis Snell <dennis.snell@automattic.com> wrote:

My goal in sharing here is to help better represent my own perspective of WordPress’ needs based on what I’ve seen. It’s long been on my list to propose a WASM RFC, but because I personally haven’t had the priority available to get an implementation working I haven’t done so. It’s my impression from the documentation that the purpose of these email threads w.r.t. RFCs is to gather interest and input before any RFC would be put together, to hold these discussions before anyone commits any major time to it.

Is your objective to support building PHP to wasm32-wasi target like it was proposed here: https://github.com/php/php-src/pull/10457? If so, the main issue with that was inability to do the zend_bailout as wasm does not support currently support setjmp and longjmp. Otherwise it’s mostly about disabling some functionality.

It’s the other way around. We’ve been having a great time already building PHP as a WASM binary - we package it with SQLite and WordPress to create “The WordPress Playground.” There’s a wonderful new world of things that can happen when packaging PHP inside a WASM runtime.

However, this is about calling compiled WebAssembly code from user-space PHP.

load_wasm( DIR . ‘/interesting-computation.wasm’ );
$description = null;
call_wasm_func( ‘lazy_json_decode’, $json, ‘items[0].description’, $description );

This is about things including, but not limited to the following scenarios:

  • Properly parsing HTML, JSON, XML, URLs, image formats, and more, but don’t want the
    severe text-processing penalty from user-space PHP code.

  • Ensuring that efficient tools are available to PHP code even when hosts don’t allow installing extensions,
    even when the site owners have no idea what an extension is or how to install one.

  • Updating libraries that convert or resize images when bug fixes are made, without having to demand
    that hosts accept that responsibility and burden themselves.

  • Share algorithms between JavaScript on the frontend and PHP on the backend, particularly those dealing
    with string processing (for example, slug generation, sanitization, decoding).

  • Explore novel software ideas and get them out to testing and iteration without having to ask the entire
    ecosystem to adopt them as extensions.

Regards

Jakub

Same! Cheers.
Dennis Snell

32

Hi,

On Fri, Sep 20, 2024 at 9:36 PM Dennis Snell <dennis.snell@automattic.com> wrote:

On Sep 20, 2024, at 1:21 PM, Jakub Zelenka <bukka@php.net> wrote:

Hi,

On Fri, Sep 20, 2024 at 6:32 PM Dennis Snell <dennis.snell@automattic.com> wrote:

My goal in sharing here is to help better represent my own perspective of WordPress’ needs based on what I’ve seen. It’s long been on my list to propose a WASM RFC, but because I personally haven’t had the priority available to get an implementation working I haven’t done so. It’s my impression from the documentation that the purpose of these email threads w.r.t. RFCs is to gather interest and input before any RFC would be put together, to hold these discussions before anyone commits any major time to it.

Is your objective to support building PHP to wasm32-wasi target like it was proposed here: https://github.com/php/php-src/pull/10457? If so, the main issue with that was inability to do the zend_bailout as wasm does not support currently support setjmp and longjmp. Otherwise it’s mostly about disabling some functionality.

It’s the other way around. We’ve been having a great time already building PHP as a WASM binary -

Ah ok I just did a bit of research and checking your wordpress-playground and it uses emscripten which actually integrates extensions to WASM (currentl proposed https://github.com/WebAssembly/exception-handling ) or it can JavaScript based support as described in https://emscripten.org/docs/porting/setjmp-longjmp.html . So it’s not actually an issue in your case. Officially PHP can still cannot be build to the official wasm32-wasi target but as I understand it’s not such a big issue because there are already viable alternatives.

Cheers

Jakub

33

On 20 September 2024 20:27:34 BST, Larry Garfield <larry@garfieldtech.com> wrote:

Logistical question, for those with more stdlib expertise: Since we have other extensions in php-src that only work if you install some other library as well (eg, curl), which distros pretty much take care of for us, would a small in-php-src extension that is just a thin wrapper for Wasmtime or similar be viable? Not embedding Wasmtime into the php-src code, just the extension, and it's up to the user/distro to install both so that they work.

This is basically what I was answering, to the best of my understanding, here <Zephir, and other tangents - Externals; and here <Zephir, and other tangents - Externals;

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.)

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. 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.

There have been a couple of mentions on this thread of writing an RFC, but I can't think of anything that an RFC could realistically propose right now. So I say again, to those of you interested in the topic: contribute to the projects already building the extensions, that's where the next steps are, not here.

Regards,
Rowan Tommins
[IMSoP]

34

On Thu, Sep 19, 2024 at 11:20 PM Mike Schinkel <mike@newclarity.net> wrote:

On Sep 19, 2024, at 12:00 PM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote:

On Wed, 18 Sep 2024, at 20:33, Mike Schinkel wrote:

Yeah. That was the original goal.

But to say WASM’s domain is limited to browsers is not valid any longer:
[…]

While it’s definitely interesting seeing what uses it’s being put to beyond the browser, the majority of those articles are talking about using WASM on its own, in the kind of places where you might use a container, to host things like microservices, serverless functions, etc.

Sigh. I did not include all potential examples. Leave it to you to limit your characterizations to only the ones I included.

Here is another:

https://github.com/wasmerio/wasmer-php

Embedding it into other languages is a different usage again. It’s certainly something that is being explored, e.g. by Extism, and that seems like a good project for anyone interested here to participate in, e.g. to help design the “glue” between PHP and WASM / Extism.

Moot point as it cannot be run on a managed hosted server.

https://github.com/extism/php-sdk

WASM’s ability to run on a managed server – assuming it were built-in
to PHP core

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

And PHP would be much less useful without any one of them.

The only runtimes where WASM is ever going to be available “out of the box” are those already built on a JavaScript engine (usually V8), like node.js, Deno, Electron, etc. The WASM is then running inside the existing runtime, not a whole new VM - like running Scala and Java code in the same JVM; or Hack and PHP in (older versions of) HHVM.

Seems you do not actually understand WASM runtimes.

While WebAssembly is available “out of the box” in JavaScript-based runtimes like Node.js, Deno, and Electron, it is not limited to them. Standalone WebAssembly runtimes like Wasmtime and WAVM allow WebAssembly to be run as a general-purpose compute target, outside the scope of a JavaScript engine.

On Sep 19, 2024, at 4:41 PM, Hammed Ajao <hamiegold@gmail.com> wrote:

Shared hosting for php gets you the worst possible version of php. Can’t recompile to enable any bundled extension, can’t install any new extensions, so how exactly would you approach this? Wasm bundled with the engine by default? Or some kind of opt in mechanism that shared hosters won’t even be able to use?

To be clear, shared hosting and managed hosting can be VERY different animals.

I am advocating for enterprise-level managed hosting — like Pantheon — not shared hosting like GoDaddy.

Ah so you want to make huge changes to the engine for even less users?

On Sep 19, 2024, at 4:12 PM, Hammed Ajao <hamiegold@gmail.com> wrote:
On Wed, Sep 18, 2024, 1:33 p.m. Mike Schinkel <mike@newclarity.net> wrote:
But to say WASM’s domain is limited to browsers is not valid any longer:

I don’t know where you got that since I never said anything along those lines.

You did not say that explicitly, but you strongly implied it. Had you not meant to imply it then you’ll argument would have made little sense because you would been implicitly admitting there are other uses for it.

I can’t tell if you’re fucking with me or not. I wasn’t commenting on whether or not there are other uses for wasm, that has nothing to do with my point. " All I did was try to explain to you why browsers need wasm and why it makes sense for them to invest in implementing it. "

But since you have all those guides and it’s so practical, what’s stopping you? You’d do a better job of convincing me with a MVP than some random blog posts.

Here you go:

https://github.com/wasmerio/wasmer-php

BTW, as you being a C++ developer your argument is rather cynical because most PHP developers do not have the skills to write PHP extensions or work with FFI, and it is not a skill that can be acquired in a few weeks worth of free time. So you saying “Just do it” can be seen by a cynical person as you attempting to shut down discussion by presenting a blocking task that you can be pretty sure is too high a technical bar for most PHP developers.

I do want to gain that skill, but I doubt that I will be able to any time in the near future, especially not with other work commitments.

You mean the feature that’s been in beta since 2022? Yeah that’s exactly what I’m referring to. If docker and all their money and engineers haven’t shipped wasm in 2 years, how long do you think it’ll take a bunch of volunteers?

Shipping as a container runtime without the surrounding support of a host is a bit more complicated than implementing within a host.

If you insist, I’ll await your MVP.

By your argument Node, Deno, and Wasmer would not have been able to ship WASM support yet.

Node and Deno do not implement wasm, V8 does. They are both V8 wrappers. V8 implements it for the browser. Wasmer is at 17000 commits. Can we afford 17000 commits focused on wasm stuff? In core?

You can’t do shit on a managed server, that is not the bar at all.

Who made you the arbiter of what the bar should be for the needs of other people?

Common sense, majority of use cases, and history.

What makes you so sure that wasm will be allowed on managed hosts? What’s the incentive for providers to allow it?

The incentives would be market differentiation and customer demand.

So maybe those companies should implement it themselves or pay to have it implemented.

For security reasons it does not matter if customers demanded FFI or extensions written in C, there is simply too much risk.

So maybe those companies should implement it themselves or pay to have it implemented.

But if there were a sandboxed secure runtime shipped with PHP, especially one that could be memory-limited and CPU-throttled, then it would be easy for some managed hosts to decide to enable it. Not all would, but channeling your imagined role as arbiter, I would say that is not “the bar.”

Extensions, which are already implemented in lower-level languages like C or C++, would still need to be compiled to WebAssembly if the goal were full compatibility.

When did I or anyone proposing WASM for PHP suggest that making compiling extensions into WebAssembly would necessarily be a blocking requirement?

This might lead us down the path of either creating a domain-specific language (DSL) for PHP—similar to AssemblyScript—or simply leaving it up to the library authors to choose lower-level languages (as is currently the case).

Or, simply allowing AssemblyScript as the initial way to use WASM in PHP core.

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? With PHP like syntax? 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.

I hear you, you want to run low level code on managed servers. I would approach the problem differently e.g. Creating some kind of directory for trusted php extensions, the criteria for what qualifies as trusted would be up for discussion. Or maybe we can bundle a small std lib of select extensions with core. Those make a lot more sense to me than adding an entire abstraction layer.

Many hosts already whitelist php extensions. That does not help.

The use-case being discussed by me and the others who commented in support of WASM is primarily bespoke code written for project-specific requirements.

I am not saying WASM has to be the thing to meets that need, but AFAIK there is no other potential similar solution that could address it. You can dismiss that goals as being unimportant or “not making sense,” but that does not mean there are not those who find meeting that need to make a lot of sense.

Let me turn it around then and ask that — rather than being the gatekeeper against a solution— you instead propose a solution to address all the following requirements:

Ability to run some form of module/add-in/extension/whatever-you-want-to-call-it in PHP that:

  1. Ships with PHP code so those managed hosts who want to enable it can easily do so,
  2. Allows for fully-bespoke project-specific things to be developed,
  3. Is reasonably easy to program in a secure way (not C or C++),
  4. Enables near native performance for things like looping and string manipulation and maths, and
  5. And is secure, can limit memory use, and can throttle CPU hogging so hosts will not object to enabling it.

Since you have already dismissed WASM as not the right approach, how would you alternately address those requirements?

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. 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.

Hammed

35

On Sat, Sep 21, 2024, 3:41 AM Dennis Snell <dennis.snell@automattic.com> wrote:

On Sep 20, 2024, at 1:21 PM, Jakub Zelenka <bukka@php.net> wrote:

Hi,

On Fri, Sep 20, 2024 at 6:32 PM Dennis Snell <dennis.snell@automattic.com> wrote:

My goal in sharing here is to help better represent my own perspective of WordPress’ needs based on what I’ve seen. It’s long been on my list to propose a WASM RFC, but because I personally haven’t had the priority available to get an implementation working I haven’t done so. It’s my impression from the documentation that the purpose of these email threads w.r.t. RFCs is to gather interest and input before any RFC would be put together, to hold these discussions before anyone commits any major time to it.

Is your objective to support building PHP to wasm32-wasi target like it was proposed here: https://github.com/php/php-src/pull/10457? If so, the main issue with that was inability to do the zend_bailout as wasm does not support currently support setjmp and longjmp. Otherwise it’s mostly about disabling some functionality.

It’s the other way around. We’ve been having a great time already building PHP as a WASM binary - we package it with SQLite and WordPress to create “The WordPress Playground.” There’s a wonderful new world of things that can happen when packaging PHP inside a WASM runtime.

However, this is about calling compiled WebAssembly code from user-space PHP.

load_wasm( DIR . ‘/interesting-computation.wasm’ );
$description = null;
call_wasm_func( ‘lazy_json_decode’, $json, ‘items[0].description’, $description );

this is a very important target which is not directly discussed in this thread.

I played with the (very good) IR when it was submitted by Dmitry back then. It sounded like the most effective way.

However it was not designed (nothing bad with that) with such goals in mind. I was hoping it could be used like any other IR (similar to what llvm does f.e.) to then target wasm. The closest one from php is python with py2wasm, but there are pretty existing solutions that make it possible, they use the out of python core approach:

https://wasmer.io/posts/py2wasm-a-python-to-wasm-compiler

which looks very much like what could be done with php as I see the chances to have that in php as very low without major changes.

best,
Pierre

It may be possible but the time required to figure it out is not something I have sadly (falling back to porting our php code to other when we need it to be used in many environments where putting a php is not an option).

As of now, I feel like writing a parser-compiler may be easier, even with limited features. But ideally the way could be to allow it the same way we can see it in other languages, but the paradigms used are very different.

All in all, it is not absolutely vital for php to have this but it will help to keep it on for the next 2 decades. Similarly to other discussions lately about new types.

best,
Pierre

36

On Sep 20, 2024, at 3:56 AM, Arvids Godjuks <arvids.godjuks@gmail.com> 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:

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 <dossche.niels@gmail.com> 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] <imsop.php@rwec.co.uk> 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”

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

On Sep 20, 2024, at 8:51 PM, Hammed Ajao <hamiegold@gmail.com> 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] <imsop.php@rwec.co.uk> wrote:
On 20 September 2024 06:20:46 BST, Mike Schinkel <mike@newclarity.net> 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:

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

37

On 23.09.2024 at 08:14, Mike Schinkel wrote:

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?"

It would be ridiculous to dismiss any software written in PHP for having
bad code, given the relatively huge amount of really bad PHP code we
still have (e.g. web-pecl). And I hope that we are not (and have not
been) generally dismissive of any PHP project whatsoever.

However, we cannot please everybody. Bundling an extension increases
the maintenance burden for the relatively few php-src developers; making
an extension mandatory, or integrating something into the core, even
more so, since we may need to also bundle and maintain external
libraries (see e.g. ext/pcre). This doesn't mean that it can't happen,
but obviously this requires the RFC process.

Regarding <https://github.com/wasmerio/wasmer-php&gt; which has mentioned a
couple of times in this thread, I'm afraid the project has been
abandoned. See e.g.
<Issues · wasmerio/wasmer-php · GitHub. But maybe someone
replies to <Issues · wasmerio/wasmer-php · GitHub. :slight_smile:

Christoph

38

On Mon, Sep 23, 2024 at 8:14=E2=80=AFAM Mike Schinkel <mike@newclarity.net>=
wrote:

> At which point, some managed hosting servers might be more willing to i=

nstall it. Not the ones who don't even install ext/curl, those are never go=
ing to benefit from this.

There are very few (if any) that won't install curl as you cannot run Wor=

dPress w/o curl. Your knowledge of what hosting providers will and will no=
t install seems to be rather dated.

Just to add to that: without curl, WordPress falls back to a limited
fsockopen-based network transport. Sometimes that's problematic, so
I'm incubating a dependency-free HTTP client that can do streaming,
async connections etc. using only functions shipped in core PHP [1].
I'll eventually propose it for WordPress core as either a better
fallback or as a replacement for curl. If PHP had WASM support,
WordPress could ship curl.wasm as a fallback and focus on the product
more than on the plumbing.

BTW, Dennis, could you see WordPress recommending a WASM extension if PHP=

bundled one here? Server Environment – Make WordPress Hosting
onment/#php-extensions

I'm not Dennis, but I think that's very real. If PHP had a solid,
official, viable WASM extension today, I'd already have a PR proposing
shipping WASM binaries with WordPress core. I'd also be advocating
everywhere to officially include the WASM PHP extension on the list of
WordPress-recommended extensions. And if that extension was a part of
every PHP build, I'd be advocating to list it as a requirement.

[1] https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPres=
s/AsyncHttp/Client.php

- Adam

39

Thanks for your thoughtful response, Mike. I hope everyone had a nice weekend.

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?”

At Automattic we’re used to working in the open. With WordPress itself (apart from Automattic) even more so. Dismissal is my bread and butter :smile: But we’re still working hard to make the web a better place and I’m happy to partner with anyone, even if we share disagreement.

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

Absolutely, though realistically we’re still talking about years before it could be required. We’re not going to alienate a broad swatch of the internet just to get a new feature. But WordPress has become more assertive in pushing updates, both on users and on hosts. There is a component of the decision that depends on how many sites are still using old versions and there is a component that looks at things like security issues, whether a version is supported, and whether hosts offer the newer versions.

WordPress today requires PHP 7.2.24, though that’s hidden in a paragraph of text after stating that the recommended minimum is 7.4. I believe that the update cycle has been contracting over time and the ecosystem is doing a much better job today at keeping updated than it was a decade ago.

My guess is that we could see rapid adoption of some WASM extensions and add it to the recommended list. This is my opinion though, and other maintainers may disagree.

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?

At this point I am realizing I might have completely misunderstood the original tangent into WASM. For one, I also find the idea of a DSL surprising for the needs being discussed. I’d like to understand better what this means, or what kind of extension would benefit from such a DSL, and what stage of the build this is being discussed (for example, a DSL for more easily writing PHP extensions in C, or a DSL like eBPF which PHP code can build as a string and submit for processing internally).

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.

What does it mean to build a WASM runtime for AssemblyScript? When I think about it, I consider a real black-box implementation with basic means of transferring primitive data types across the barrier. In JS we have numbers and shared memory buffers. This leaves many things wanting, but also is “enough” and makes the security domain much smaller and easier to ensure.

I’m not sure how to visualize what people are discussing when they talk about designing something for AssemblyScript. Would that exclude the ability to run C applications or Rust applications compiled to WebAssembly?

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.

We can flip the discussion, too. The idea of running code on a WASM runtime from PHP isn’t just about stuffing new complexity into PHP. The day we require a WASM runtime is the day we can drop almost every other PHP extension from the required list. It’s great having curl and exif and pcre available, but the fact that they may not be makes every call out to them a liability - every call needs to a fallback implementation in user-land PHP or else we’re going to have to deal with site crashes.

Even extensions like mb_string are incredibly useful, but only because we don’t have access to tools that better fit the needs we have as a CMS. There are some very surprising code snippets that exist (a) because mb_string isn’t guaranteed to be there and (b) because the interface is close enough to look right but different enough to be extremely awkward.

One quick example comes up from just two nights ago: detecting URLs. We want to have a Unicode-aware strspn() function, so we have to use PCRE with the Unicode flag set. Now we have dependencies on extensions and no practical fallback, also the code in JavaScript cannot be the same because they use different regular expression syntax and people have to manually and correctly translate that. (Well, I have proposed some user-space PHP code to provide a streaming UTF-8 decoder, but it’s much slower than the C code inside PHP or the WASM binary would be). One new algorithm, compiled to WASM, could return the byte-offsets into a string where URLs are detected and then the PHP and JS could have a stable agreement and it wouldn’t depend on any other extensions than WASM.

Having spent years dealing with text encoding issues I’d cheerly replace existing mb_ code in WordPress with custom functionality as a WASM module. And again, I want to highlight that this is a win for hosts. Nobody needs to ask their host to install new extensions, no host has to evaluate the security or reliability of an extension. Nobody has to come begging for a rapid update to openssl because some vulnerability gave internet visitors root-level access on the host’s server. Nobody has to be disappointed because their host refuses to make libvips available to PHP code for the one site on their service that wants it. Hosts can start removing extensions that have long been headaches but are so necessary in practice that they can’t get rid of them.

——

This was supposed to be a very brief response. Sorry, and thanks for your patience reading through to the end. I’m responding because I feel like the conversation is relevant and good, but my tone is meant to be friendly with a realizing that none of this stuff is likely happening rapidly, and nobody is demanding this work. I want PHP to grow and mature, as I hope all here do, and I’m sharing where I can see WASM being the missing piece that we’ve wanted or needed for a long time to relieve pressure from the core language and escape from many of the legacy warts that make building reliable performant software in PHP so difficult.

Warmly,
Dennis Snell

40

On 23/09/2024 18:07, Adam Zielinski wrote:

If PHP had WASM support,
WordPress could ship curl.wasm as a fallback and focus on the product
more than on the plumbing.

As has been pointed out a couple of times already, this particular use case really doesn't stand up to scrutiny.

- The chances of PHP making it a requirement that everybody who installs the PHP runtime *must* also install a WASM runtime are close to zero. It's actually much more plausible (though still unlikely) that we would make libcurl a hard requirement.
- Hosts who do not install ext/curl because they don't trust it are very unlikely to trust something as complex and versatile as a WASM runtime.
- Hosts who do not install ext/curl because they only install the base package provided by Ubuntu/RedHat/Alpine/etc won't install an ext/wasm, because it won't be included in that base package. I can't stress enough that those base packages are not "the default build of php-src", they are entirely controlled by the package managers at each distribution/repository.
- Hosts who already install a variety of PHP extensions will already install ext/curl, so are not relevant *for this particular example*.

The use case I *can* see is for *high-end* hosting services, who already install a range of extensions, including ext/curl, but don't allow users to upload binaries. (Mike gave the example of Pantheon.) They might allow users to upload and run more niche extensions, if it was proven that WASM provided a better sandbox than just running binary code inside an OS container.

I don't actually know what market share that kind of service has, with cheaper shared hosts on one side, and container-based hosting like DigitalOcean (where you can upload native binaries already) on the other.

Regards,

--
Rowan Tommins
[IMSoP]