Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHP: Stream downloading/processing of remote resources #1028

Closed
adamziel opened this issue Feb 11, 2024 · 1 comment
Closed

PHP: Stream downloading/processing of remote resources #1028

adamziel opened this issue Feb 11, 2024 · 1 comment

Comments

@adamziel
Copy link
Collaborator

adamziel commented Feb 11, 2024

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 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.
@adamziel
Copy link
Collaborator Author

adamziel commented Oct 24, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

1 participant