You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Blueprints download and extract zip files. They initiate multiple requests at a time, which is natural in JavaScript but a bit more cumbersome in PHP. The PHP library could support that with a remote fopen() call or multihandle CURL requests – although CURL isn't supported by Playground yet.
The WASM implementation would delegate these network calls to fetch(). We'd need a PHP-JS bridge to pass chunks of stream data from Response.body to fread() calls. The current proc_open() implementation does something similar – it creates a pipe, connects the "write" end to a fake device we can write to in JS, and connects the "read" end to the PHP runtime where we can use it with fread() or stream_get_contents().
A few challenges related to calling fetch() from PHP:
The PHP runtime needs to be loaded first. However, the browser could start fetch()-ing before the .wasm binary is fully downloaded. We could start resolving them early using JavaScript code at the expense of maintaining two resource resolvers: one written in JS, and one written in PHP.
CORS issues – Calling fetch() from a web worker means they'll originate from playground.wordpress.net. It would be nice to delegate the fetch() call to the website where the <iframe src="https://playground.wordpress.net" /> is displayed.
The PHP library will also need to report the download progress. It could do that by dispatching events. These events would be reported using an ASCII progress bar in CLI, and using a graphical progress bar in the browser. The JavaScript implementation of Blueprints would need to listen to these progress events like php.addEventListener("progress").
Action items
Enable PHP.wasm to stream-read from multiple URLs.
Decide: Should Playground maintain a separate, JavaScript-based Blueprint Resource resolver?
Find a way of calling fopen("https://...") in a web worker, calling fetch() on the website where Playground is embedded, and transferring the response stream back to the web worker.
Transmit progress information from the PHP program to JavaScript code.
The text was updated successfully, but these errors were encountered:
Solved by #1926. For resolving Blueprint resources in PHP, the PHP would initiate a network connection via TcpOverFetchWebsocket, and the JavaScript engine would only need to plug it into an existing Response object instead of initiating a new fetch() request.
A part of Blueprints: Transition from a TypeScript library to a PHP library
Blueprints download and extract zip files. They initiate multiple requests at a time, which is natural in JavaScript but a bit more cumbersome in PHP. The PHP library could support that with a remote
fopen()
call or multihandle CURL requests – although CURL isn't supported by Playground yet.The WASM implementation would delegate these network calls to
fetch()
. We'd need a PHP-JS bridge to pass chunks of stream data fromResponse.body
tofread()
calls. The currentproc_open()
implementation does something similar – it creates a pipe, connects the "write" end to a fake device we can write to in JS, and connects the "read" end to the PHP runtime where we can use it withfread()
orstream_get_contents()
.A few challenges related to calling
fetch()
from PHP:fetch()
-ing before the.wasm
binary is fully downloaded. We could start resolving them early using JavaScript code at the expense of maintaining two resource resolvers: one written in JS, and one written in PHP.fetch()
from a web worker means they'll originate from playground.wordpress.net. It would be nice to delegate thefetch()
call to the website where the<iframe src="https://playground.wordpress.net" />
is displayed.The PHP library will also need to report the download progress. It could do that by dispatching events. These events would be reported using an ASCII progress bar in CLI, and using a graphical progress bar in the browser. The JavaScript implementation of Blueprints would need to listen to these progress events like
php.addEventListener("progress")
.Action items
fopen("https://...")
in a web worker, callingfetch()
on the website where Playground is embedded, and transferring the response stream back to the web worker.The text was updated successfully, but these errors were encountered: