5 ms·

That article doesn't explain what the WASM code does in Drupal.

berkes 3y ago
I understood that Drupal/php is compiled to WASM and then run on a WASM runtime. So no WASM inside Drupal, but Drupal run as, and in WASM.
- angelmm 3y ago
  Exactly. The Drupal code is unmodified and runs on top of the PHP interpreter compiled to Wasm [0]. The Drupal PHP code is not compiled to Wasm. - [0] https://github.com/vmware-labs/webassembly-language-runtimes https://github.com/vmware-labs/webassembly-language-runtimes
  - berkes 3y ago
    Is that possible, though? To compile PHP to WASM seems possible¹, but not sure if Drupal can be compiled: drupal does (did? back when I did Drupal it certainly did. I certainly did) some really funky metaprogramming and eval() stuff. Like keeping PHP in the database. ¹https://github.com/wapm-packages/php https://github.com/wapm-packages/php
gzurl 3y ago
I think you missed this paragraph: The Apache HTTP server and the Drupal packages remain unchanged. However, instead of loading the libphp.so extension module, it incorporates mod_wasm.so. In addition, instead of relying on the traditional PHP interpreter, it utilizes a PHP build in the WebAssembly binary format.
- SoftTalker 3y ago
  So instead of trusting libphp.so, you have to trust mod_wasm.so that is running a php interpreter internally. Is this a win? Genuine question.
  - assambar 3y ago
    The biggest gain comes from mod_wasm using a Wasm runtime to run the PHP interpreter in a sandboxed environment. And mod_wasm can be used the same with Python or Ruby, or anything that builds for WebAssembly. - No errors (even fatal) from the Wasm module will bring down Apache HTTPD. - mod_wasm's code base is small enough to inspect thoroughly and test thoroughly to ensure it is secure - Indeed you will now have to trust the embedded Wasm runtime (wasmtime as of today). As a naïve analogy, this is the equivalent of trusting a virtual CPU(Wasm)+OS(WASI), which gets tested in thousands of other scenarios than the ones used in mod_wasm and issues get fixed and corrected asap.

I understood that Drupal/php is compiled to WASM and then run on a WASM runtime. So no WASM inside Drupal, but Drupal run as, and in WASM.

angelmm 3y ago
Exactly. The Drupal code is unmodified and runs on top of the PHP interpreter compiled to Wasm [0]. The Drupal PHP code is not compiled to Wasm. - [0] https://github.com/vmware-labs/webassembly-language-runtimes https://github.com/vmware-labs/webassembly-language-runtimes
- berkes 3y ago
  Is that possible, though? To compile PHP to WASM seems possible¹, but not sure if Drupal can be compiled: drupal does (did? back when I did Drupal it certainly did. I certainly did) some really funky metaprogramming and eval() stuff. Like keeping PHP in the database. ¹https://github.com/wapm-packages/php https://github.com/wapm-packages/php

gzurl 3y ago

I think you missed this paragraph: The Apache HTTP server and the Drupal packages remain unchanged. However, instead of loading the libphp.so extension module, it incorporates mod_wasm.so. In addition, instead of relying on the traditional PHP interpreter, it utilizes a PHP build in the WebAssembly binary format.

SoftTalker 3y ago
So instead of trusting libphp.so, you have to trust mod_wasm.so that is running a php interpreter internally. Is this a win? Genuine question.
- assambar 3y ago
  The biggest gain comes from mod_wasm using a Wasm runtime to run the PHP interpreter in a sandboxed environment. And mod_wasm can be used the same with Python or Ruby, or anything that builds for WebAssembly. - No errors (even fatal) from the Wasm module will bring down Apache HTTPD. - mod_wasm's code base is small enough to inspect thoroughly and test thoroughly to ensure it is secure - Indeed you will now have to trust the embedded Wasm runtime (wasmtime as of today). As a naïve analogy, this is the equivalent of trusting a virtual CPU(Wasm)+OS(WASI), which gets tested in thousands of other scenarios than the ones used in mod_wasm and issues get fixed and corrected asap.