- 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/
What's the purpose of this POC? Is it to create a miniapp platform or to build a web experience that's better in terms of performance? If you're aiming to develop miniapp, fully following the current WeChat miniapp format would be the best approach, allowing compatibility with existing miniapp code (this is also how other major apps in China are doing it). But the workings of these miniapp are very transparent, so it seems there's no need to do a POC?