- Embedder use the filesystem as a cache for assets
- Manifests also stored on the filesystem, but loaded in memory on start-up.
- Mini-app registered with the embedder: store manifest and assets.
- Emebedder registers mini-apps with a new message to Servo.
- Registering a mini-app means:
- registering a networking override when the user navigates to the mini-app url.
- When handling the navigation override:
- the embedder uses the manifest to load resources from the filesystem, and
- makes them available to script as fetch responses.
- For simplicity: just write the content of all assets to an HTML file(containing no links) and load it in one go?
- This implies an un-registration mechanism.
- The mini-app runs on a window event loop, like any other web app.
- what about non-standard architectural features of current mini-app frameworks?
- Running a business logic worker JS thread outside of Servo? I think this could be done with a normal web worker, but the above design would allow the embedder, as part of the network interception hook, to start such a thread outside of Servo. Outside of the scope for a POC(would require more mechanisms to communicate with the window event-loop).
- JS bridge to OS: use web standards instead?
- Supporting non-standard mark-up is outside of the scope of a POC. Also, it seems that Web standards could be used instead.
- In general, implementing mini-apps in Servo should prefer Web standards approach, see the MiniApp APIs Gap Analysis.
- Good general explainer on current mini-apps frameworks found at: https://web.dev/articles/mini-apps/
Does this POC use native HTML tags (div, span, input) for the UI, or use mini-app-like WXML (text, view, button)?
I've been stuck on a decision about this for a while. Mini app have a key difference compared to the web — they're mature, highly encapsulated development frameworks. Developers don't need to use frameworks like React or Vue to assist in development (though you can use them, but they eventually get compiled into mini app source code). With the web, exposed elements and methods are very basic and highly flexible, making it tough to use vanilla JS for direct web development.
So, the question is, what direction should the new high-performance web take? Should it be a more highly integrated framework with efficient native development, or maintain the current low-level flexibility and let the community solve the development efficiency problems?