> On Sep 19, 2024, at 12:00 PM, Rowan Tommins [IMSoP] <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
> On Wed, Sep 18, 2024, 1:33 p.m. Mike Schinkel <[email protected]> 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:
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.
> - https://docs.docker.com/desktop/wasm/
>
> 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