On 20 September 2024 06:20:46 BST, Mike Schinkel <m...@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]
