search

wintercg / proposal-minimum-common-api

https://min-common-api.proposal.wintercg.org/
Other
229 stars 13 forks source link

Could embedded systems also use the Common Minimum API? #20

Open phoddie opened 2 years ago

phoddie commented 2 years ago

While this initiative is focused on JavaScript interoperability for the web, it may also be valuable for JavaScript runtimes for embedded systems. Developers working in JavaScript on embedded systems are already using the programming language of the web. It makes sense for JavaScript developers who work on both embedded systems and the web to use interoperable APIs. While the resource constraints of some embedded systems limit where this is practical, there is already a significant intersection with the draft Common Minimum API.

During OpenJS World 2022 in Austin, @dtex and I had a conversation with @jasnell about whether it would be appropriate for the WinterCG initiative to also address embedded systems. Given the overlap in technologies and developers, we agreed that it was worth exploring. To begin the conversation, it was suggested that I prepare a summary of the APIs under consideration by WinterCG that are also relevant to embedded systems from the perspective of my work with Ecma TC53 (ECMAScript Modules for Embedded Systems) and Moddable. The Moddable SDK provides the most complete implementation to-date of Ecma-419 and so informs these notes.

The following notes are based on the "Minimum Common Web Platform API" draft of May 26, 2022. In all cases, any implementation referred to is a subset of the full web platform APIs.

These are supported in the Moddable runtime. The TextDecoder implementation accepts only UTF-8 input.

In addition to API compatibility, there is a question about how code accesses the constructors. In the Moddable runtime, just about everything is a module, so these are accessed by import of text/encoder and text/decoder. Our runtime environments can be set-up for compatibility that assign these modules to globals or provide access via alternate module paths. Will WinterCG address how these are accessed or is it implicit that it will always be via a global?

URLSearchParams is implemented as part of the fetch module in the Moddable SDK, which is built on the HTTP request API proposal for Ecma-419 2nd Edition. URL and URLPattern could also be provided.

This fetch module also includes Headers which is required for fetch. Could Headers be in-scope for WinterCG?

For compatibility with web platform code, embedded runtimes often include a minimal implementation of console. It would be welcome to have a known subset of methods (and their required behaviors) to target for interoperability.

TC53 considered including these functions in the the first edition of the Ecma-419 standard but deferred them because of the overlap with other standards.

The Moddable runtime implementation of Ecma-419 provides these functions by building on a lower level Timer object. The implementation is not strictly web compatible, using an object for the timer rather than integer and ignoring the passthrough arguments.

Streams are not currently supported because they are too heavy as a foundational building block for many embedded devices. However, they are being evaluated as an option for scenarios and devices where they can work. For example, streaming with fetch may be feasible only on more capable microcontrollers with the required memory and CPU power.

The Moddable runtime provides modules for zlib compression and decompression that emulate the pako API. This could be used as a basis to implement CompressionStream and DecompressStream if Streams prove feasible.

There are scenarios where these could be valuable, but they are not immediate. Consequently, while these global functions are not currently provided in the Moddable runtime, they could be.

Ecma-419 does not specify functions or objects for cryptography. However, the need exists, especially because some microcontrollers contain hardware to accelerate and/or secure cryptographic primitives.

Neither Ecma-419 nor the Moddable runtime requires events. However, some web APIs which are relevant to embedded systems depend on events (see W3C Sensor below and the Moddable runtime implementation of WebSocket using Ecma-419), making these relevant.

Ecma-419 defines the Sensor Class Pattern for access to sensor data. The Sensor Class Pattern is designed to be a building block to implement W3C Sensor for various sensor types. Perhaps none of the non-browser web platform runtimes are using sensors yet, so this is outside the scope of WinterCG.

FWIW, W3C Sensor support has been explored in the Moddable runtime using implementations of the Sensor Class Pattern. It works well. The main interoperability issue is with Events, as these assume the full Event API support of the browser. The Moddable runtime provides a minimal implementation of events for W3 Sensor. Perhaps

jasnell commented 2 years ago

@phoddie ... just wanted to drop a quick note to say I've seen this but haven't been able to get back to it. I should be able to this week

phoddie commented 2 years ago

I have a couple updates to the original notes to share:

These are now implemented. URL passes nearly all the web platform tests with two exceptions: Punycode and and IDNA support are unimplemented. The problems these solve are not generally a concern on embedded systems. With some effort (and increase in code size), the implementation could support both.

This is now fully supported.

A deepEqual function mirroring Node.js is now also supported, but this does not appear to be a current candidate for the Common Minimum API.

trusktr commented 1 year ago

I'm working on compiling TS to Wasm and native. I think this would be great, factoring in how it plays with Wasm (by extension native), and a great alternative to WASI because WASI is not concerned with Web but with providing a common but very non-Web interface for legacy code (f.e. existing C/C++ code).

It would amazing to have a standard for Wasm that works great in both browser and non-browser Wasm.