> On Sep 20, 2024, at 1:21 PM, Jakub Zelenka <bu...@php.net> wrote: > > > Hi, > > On Fri, Sep 20, 2024 at 6:32 PM Dennis Snell <dennis.sn...@automattic.com >> wrote: > >> >> >> >> My goal in sharing here is to help better represent my own perspective of >> WordPress’ needs based on what I’ve seen. It’s long been on my list to >> propose a WASM RFC, but because I personally haven’t had the priority >> available to get an implementation working I haven’t done so. It’s my >> impression from the documentation that the purpose of these email threads >> w.r.t. RFCs is to gather interest and input before any RFC would be put >> together, to hold these discussions before anyone commits any major time to >> it. >> >> >> > > Is your objective to support building PHP to wasm32-wasi target like it was > proposed here: https://github.com/php/php-src/pull/10457 > ? If so, the main issue with that was inability to do the zend_bailout as > wasm does not support currently support setjmp and longjmp. Otherwise it's > mostly about disabling some functionality. > >
It’s the other way around. We’ve been having a great time already building PHP as a WASM binary - we package it with SQLite and WordPress to create “The WordPress Playground.” There’s a wonderful new world of things that can happen when packaging PHP inside a WASM runtime. However, this is about calling compiled WebAssembly code from user-space PHP. load_wasm( __DIR__ . ‘/interesting-computation.wasm’ ); $description = null; call_wasm_func( ‘lazy_json_decode’, $json, ‘items[0].description’, $description ); This is about things including, but not limited to the following scenarios: - Properly parsing HTML, JSON, XML, URLs, image formats, and more, but don’t want the severe text-processing penalty from user-space PHP code. - Ensuring that efficient tools are available to PHP code even when hosts don’t allow installing extensions, even when the site owners have no idea what an extension is or how to install one. - Updating libraries that convert or resize images when bug fixes are made, without having to demand that hosts accept that responsibility and burden themselves. - Share algorithms between JavaScript on the frontend and PHP on the backend, particularly those dealing with string processing (for example, slug generation, sanitization, decoding). - Explore novel software ideas and get them out to testing and iteration without having to ask the entire ecosystem to adopt them as extensions. > > Regards > > Jakub > > Same! Cheers. Dennis Snell