On 20 September 2024 06:20:46 BST, Mike Schinkel <[email protected]> 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]