If I did some significant work on this repo (touching almost every file), would you merge it?

[cweagans]

I would like to rework this repository into something more widely usable in the PHP community. Here are a few things that I've noticed:

• A PHP extension is required to do anything. This is probably the single biggest thing blocking wide adoption of this library. The vast majority of PHP applications are hosted on shared hosting providers that don't allow installing/loading additional PHP extensions. Even for the ones that are hosted on e.g. a VPS or whatever, installing some random PHP extension is not a common thing.
• Because the extension exposes the wasmer engine as a resource in PHP, it's impossible to write a pure PHP polyfill that would e.g. use FFI or similar to get the same functionality. It's not possible to create a new resource type directly in PHP and it is also not possible to pretend that an object is an instance of a particular resource type, so even if I write a class that has the same interface as your resource, I still can't pass it in as an argument to the constructor of e.g. \Wasm\Module. There are a couple of libraries that I'm aware of that rely on an extension, but have a pure PHP implementation as a fallback -- even if that's just via FFI. FFI is a relatively new thing to PHP, but I think it's still a viable path for people using PHP 7.4 or higher.
• Because many of the classes are final, I also can't extend the class and make the changes that I need to make in order to support the above on my own.
• Details about the wasmer engine need to be known to the developer in order to effectively use this library. I'm not sure that this is actually based on any real technical requirement though -- it should be possible to expose a limited but very straightforward interface to developers that encapsulates those details. As a very simple example, maybe something along the lines of:

// file.wasm exports add and multiply functions and a myval value
$wasm = \Wasm::load('/path/to/my/file.wasm');

echo($wasm->add(1, 2));
echo($wasm->multiple(2, 4));
echo($wasm->myval);

This would more or less be a 2.x version of this library (I'm not sure how you'd do this without a BC break). Maybe it's of interest?

[sjsone]

@cweagans Considering the inactivity of this repository, I suggest forking it with your proposed changes.

I am willing to volunteer to help implement the necessary changes if you would like, as I strongly believe that a WASM extension for PHP would be a valuable addition.

[veewee]

@cweagans / @sjsone

Sounds like a plan, given the unmaintained state of this repository.
Nevertheless, it would be nice if the authors could give some insights in how they see this package evolve. /cc @wasmerio

To answer your questions from my outsider point of view:

A PHP extension is required to do anything. This is probably the single biggest thing blocking wide adoption of this library. The vast majority of PHP applications are hosted on shared hosting providers that don't allow installing/loading additional PHP extensions. Even for the ones that are hosted on e.g. a VPS or whatever, installing some random PHP extension is not a common thing.

I don't think wasm in PHP will be adopted if it is not being shipped in PHP's core. Yet I believe if this can get into PHP's core some day, it will boost the whole ecosystem. Not only for the obvious performance reasons, but imagine sharing logic between PHP+JS in frameworks like livewire: there would be no reason to rerender on the server anymore.

Because the extension exposes the wasmer engine as a resource in PHP, it's impossible to write a pure PHP polyfill that would e.g. use FFI or similar to get the same functionality. It's not possible to create a new resource type directly in PHP and it is also not possible to pretend that an object is an instance of a particular resource type, so even if I write a class that has the same interface as your resource, I still can't pass it in as an argument to the constructor of e.g. \Wasm\Module. There are a couple of libraries that I'm aware of that rely on an extension, but have a pure PHP implementation as a fallback -- even if that's just via FFI. FFI is a relatively new thing to PHP, but I think it's still a viable path for people using PHP 7.4 or higher.

It won't be possible to write a pure PHP polyfill and you will need FFI if you want to provide a polyfill. Yet, It might beat the purpose though: you want to execute webassembly in a sandboxed environment, but run it in a fully opened up environment in which you create a sandbox instead. But sure, it is possible!
I don't think the extension needs to provide any resource or resource wrapper (see next points).

Because many of the classes are final, I also can't extend the class and make the changes that I need to make in order to support the above on my own.

Shouldn't it be sufficient for an extension to provide a stub file? That way static analyzers know how it behaves.
Adding wrapper classes to access e.g. exported functions inside the wasmer instance could be done in a seperate package. Adding it to the extension package doesn't seem to be the right place.

Details about the wasmer engine need to be known to the developer in order to effectively use this library. I'm not sure that this is actually based on any real technical requirement though -- it should be possible to expose a limited but very straightforward interface to developers that encapsulates those details. As a very simple example, maybe something along the lines of:

You are right! The python wasmer bindings return primitive types as well instead of there wrapper values. It sure is possible!

My point of view

I think we both agree there is a lot of room for improvement in this inactive package.
How I would like to see the implementation evolve:

• Create a rust based PHP extension: I think one of the things that is blocking this package from evolve, is that it is written on top of the C bindings directly. Maybe it would be easier to maintain if it is written in rust instead.
• Provide stub files instead of the interfaces
• Optionally provide a FFI based alternative
• Optionally provide an optional PHP package that provides interfaces / wrappers around the instances

I've been playing around with the wasmer rust bindings in combination with ext-php-rs (PHP bindings in rust) and set up a little POC:

• https://github.com/veewee/ext-wasm

Sure it is full of shortcuts... The goal of the POC is to see if it was possible to:

• execute WASM through the PHP rust bindings - as simply as possible
• avoid leaking internal resources
• use scalar types instead of wrappers

How to go forward

I'm not sure... I see a couple of routes:

• We try to revive this repository somehow and continue in C.
• We start from scratch in a new repository (either in wasmerio organisation or in another organisation - php-rust-tools might be interested...)

In any case, I am also convinced we should be able to run wasm in PHP!
My rust skills are very rusty, but I'm willing to learn and collaborate.

[sjsone]

Hey @veewee,

Thanks for your input on the WASM extension for PHP repository. Your feedback is much appreciated!

I agree that Rust would be a great choice for this project and could potentially improve its functionality or at least make our lives easier.
However, I do have concerns that using Rust may hinder our ability to integrate the extension into the PHP-Core.
But I don't know if it is really a bad thing? And maybe it could kickstart some changes in the PHP-Core so who knows...

I'm also wondering if it might be a good idea to start a new repository or organization for this project, as the current one looks a bit stale.

By the way, I noticed that https://github.com/veewee/ext-wasm appears to be a private repository, so I wasn't able to take a closer look.

Thanks again for your help and insight! Looking forward to collaborating further.

[veewee]

Thanks for noticing, it should be public now.

I don't know what php internal's view on using rust or even wasm is nowadays.
But the project could at least be used as a proof of concept to base the discussion of a core extension on - if there is any interest of the core members.
If there is no interest, then it can still be used as a third party extension.

Not sure if that unknown is something we should use to base the technology upon though.

[cweagans]

IMO, take this one step at a time: get the extension working for a large number of people first. If the PHP code can use an extension or FFI to handle loading and running the WASM blob, then it'll work on pretty much any host (IIRC, FFI is enabled by default in PHP 7.4 and above).

Just so that nobody is waiting on me: I probably will not work on this.

[veewee]

No problem @cweagans .

I'm going to play a bit more with the rust bindings anyways, step by step.
FFI won't be available on a lot of hosts given the security risk it has. I think it's also only enabled on cli by default.
Anyways, I'll check out what is possible :)
Thanks for the feedback!