Google's WorkerDOM does not have any event algorithm.
It partially has some implementations, such as
The event algorithm goes much more profound than that.
Then, Brane should cover very partial JS APIs. The question goes: how do we know what will be the core and what will be plugins?
Note that the division between core and plugin should be the importance of each feature, not size.
- For the format, it could be anything.
- Use iframe sandbox for the outer side.
- Use a variant of WorkerDOM inside.
- WorkerDOM will be an arbiter between the worker thread and the iframe.
- WorkerDOM will harness SharedArrayBuffer.
- the question revolves: what DOM API should WorkerDOM support?
- We don't know for sure now, but at least the History & Location APIs.
Since Brane implements an arbiter, which spans more than just a DOM... We should be able to decline whatever is not allowed.
- Host: The main thread app
- Guest: Untrusted, third-party app that should be containerized.
Primary goals in Demo
- Non-blocking (Guests' operation cannot affect the normal execution of the Host.)
- Isolated (Guests can never unauthorizedly affect the Host)
- Submissive (the Host can forcefully shut down guests)
Preferably, WorkerDOM and Worker API will already have a non-blocking operation feature. Needs confirmation.
We should start from isolation.
Then, the next step is to investigate how deep isolation does
iframe sandbox provides.
- An Isolate Cloud is similarly a compute abstraction but uses the most minimal package possible: only the application code.
It seems like Deno envisions a Vercel-like experience for the backend (FaaS.)