second-state / wasmedge-quickjs

A high-performance, secure, extensible, and OCI-complaint JavaScript runtime for WasmEdge.
Apache License 2.0
477 stars 59 forks source link

[Question] Http support #105

Open Wonshtrum opened 1 year ago

Wonshtrum commented 1 year ago

I've noticed that certain key features are currently missing in the wasmedge-quickjs repository, which may not be prioritized at the moment. Firstly, there is no HTTPS support, and I also encountered a long-standing bug (#102) related to the response buffer length, which rendered the fetch functionality unusable in my tests.

I'm currently working on a project that uses a custom WASM WASI runner, and I believe the wasmedge-quickjs project could be a valuable resource for JavaScript support. However, there are a few essential features that are lacking for my use case, namely HTTPS support and a complete implementation of the Response/Request standards. While I managed to address the HTTPS aspect by rewriting the Rust part to accommodate my custom networking hostcalls, I'm finding it more challenging to work with the JS SDK.

Specifically, I require the ability to stream data with the .body -> ReadableStream API on the Response and Request objects, along with the standard response constructor constructor(body, options) instead of the current constructor(resp, buffer, reader, option = {}). It would greatly benefit me if the library could provide as much of the standard API as possible, allowing my users' code to run with minimal modifications.

I'm curious to know if there are any plans for development in this area or if it aligns with your future roadmap for the networking API. If not, I'm willing to contribute and implement these features myself. Would you be interested in my contributions, or would it conflict with your plans?

Additionally, I noticed that quickjs doesn't implement ReadableStream/WritableStream, but the modules/internal/streams folder contains Readable and Writable functions. Apart from the naming difference, are there any significant distinctions between these functions and the standard ReadableStream/WritableStream objects? Could they potentially create difficulties for users or require them to make adjustments?

L-jasmine commented 1 year ago

Thank you very much for your issue and PR.

Regarding the issue 102, which is the bug in Buffer::byteLength, I would prefer to add a new field instead of changing the existing Buffer::length to Buffer::byteLength.

As for HTTPS, it is currently being worked on and will be supported this week.

Regarding the ReadableStream/WritableStream objects, it's not that I haven't implemented them, but rather that I am very familiar with JavaScript. I would greatly appreciate it if you could provide the corresponding PR.

Wonshtrum commented 1 year ago

Yes adding the field instead of replacing it seems like a good idea. It's nice to know that HTTPS is being implemented. I will be working on the standardization of the Request and Response API. If it doesn't rely on my custom features I will contribute to this repository.

ShayanShiravani commented 11 months ago

Hi. When do you plan to release HTTPS support?