@rysiek btw, this is a bit silly, but could a service worker just use sendmessage to communicate with the main page which hosts an RTCDataChannel in lieu of instantiating an RTCDataChannel itself?
this idea comes from the fact that the current API (as implemented by Safari) needs a webpage to establish the RTC channel, which then gets sent to the worker (and probably only lives as long as the page is open). so in practice, the worker first has to serve some kind of shim webpage and script, which establishes the channel and sends in to the worker – then the worker could use the channel to answer further requests
so the silly thing to do would be to (in absence of RTC channel transfer support) establish the channel in the shim webpage, and notify the worker of this fact via a message. subsequently, on any fetch request the worker would send a message to the webpage, and the webpage would answer with another message transferring some buffer with the request data. this is of course completely backwards, but FetchEvent.respondWith does take any promise, and Response objects can be created from scratch (albeit with some CORS caveats)…
@kristof @midzer @fribbledom
> btw, this is a bit silly, but could a service worker just use sendmessage to communicate with the main page which hosts an RTCDataChannel in lieu of instantiating an RTCDataChannel itself?
In general terms: sure, this is actually used by an js-ipfs example somewhere.
Specifically for my project: no, the point is to have a way to fetch content even before any HTML is loaded (provided that the SW has been installed before):
mastodon.technology is shutting down by the end of 2022. Please migrate your data immediately. This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!