xuset
Research the Tag Editing Approach
Using the service worker to intercept HTTP requests has many benefits; however, for our initial use case, blogs and small websites, it is not as well suited as modifying resources in the HTML. Thus, we need to investigate tag editing and decide on an approach that allows us serve this initial use case and scale to more complex use cases as well.
Benefits of Service Worker:
- Intercepts all network requests
- Better API
- Doesn't require manipulating user code
- Works even if the web server is down (for static websites)
- Loads the index page over HTML after the SW is installed
- Early in the adoption curve
Benefits of Tag Editing:
- Initial website load can be done over WebTorrent (except for index file)
- Videos can be streamed in browsers other than Chrome
- Doesn't require including a script in the index file
It should be noted that these approaches are not mutually exclusive; I think it makes sense to enable the service worker and build-time tag editing by default. However, the code for both of these systems are completely unrelated, so they should be separated into different repositories.
I'm going to start out with the parse5 HTML parser: https://github.com/inikulin/parse5
It is used in Angular and Polymer, so its probably pretty stable.
Tags that need to be edited: <audio>, <base>, <iframe>, <img>, <link>, <object>, <picture>, <source>, <track>, <video>
Resources:
- Example of how to render WebTorrent files/streams to the DOM (https://github.com/feross/webtorrent/issues/879#issuecomment-280576761)
High Level Design Overview:
In order to make the engineering of tag editing easier, we need to separate Planktos into multiple components: lib, service worker, tag editor, and CLI. The flexibility that Planktos offers users is currently abstracted away into the service worker component, which we provide opinionated implementations of e.g. resiliency for static websites and CDN for video. Since there are now multiple paths to intercepting requests for static resources, we need to introduce the onIntercept event handler, which users can customize in order to serve different use cases. This event handler will run upon rendering the page or in the service worker upon intercepting a network call, allowing the user to customize the behavior of Planktos without having to consider the way that the call was actually intercepted.
The tag editing component is going to require editing the user's HTML in the build phase, dynamic rendering of edited tags (can be disabled if WebTorrent isn't supported), and execution of the user defined onIntercept event handler. Additionally, we are going to utilize this build phase to include the code for dynamic rendering and the SW install script.