[w3c/ServiceWorker] Make WebRTC usable as a backend for Service Workers to fulfill requests from a peer-to-peer network (#1522)

This is the other half of the WebRTC spec issue with the same name: https://github.com/w3c/webrtc-pc/issues/2553

People trying to use WebRTC to spin up peer-to-peer network nodes in the browser are running into trouble attaching the peer-to-peer capabilities of WebRTC to the request-handling capabilities of ServiceWorker.

In addition to making the API available to the Service Worker context, as tracked by the issue on the WebRTC spec, the section of the Service Worker spec [on worker lifetime](https://w3c.github.io/ServiceWorker/#service-worker-lifetime) would need to be revised. It currently says:

> The lifetime of a service worker is tied to the execution lifetime of events and not references held by service worker clients to the ServiceWorker object.
>A user agent may terminate service workers at any time it:
> *   Has no event to handle.
> *   Detects abnormal operation: such as infinite loops and tasks exceeding imposed time limits (if any) while handling the events.

Since receiving events from peers isn't exactly abnormal operation (in the same way that repeated `setTimeout()` would be), but we'd still want to allow the worker to shut down while other peers are talking to it, this section would need to be revised to allow the user agent to kill the worker in more circumstances.

Additionally, to make the peer-to-peer-node-in-service-worker use case really work well, the Service Worker needs to be able to expect to have a longer lifetime than just that required to handle a single request (because a peer-to-peer network is no good if nobody can seed data back after downloading it). I would recommend that the spec suggest that a service worker instance be allowed to persist as long as any of its controlled tabs are open, and as long as it is serving a request for any file being downloaded to disk by the user agent. This buys the site very little it couldn't get by just embedding JS on the page in terms of the ability to use memory and drain battery, but provides the nice ergonomic Service Worker interface for handling requests.

It's unclear right now how a service worker fulfilling a very long running request ought to be handled. When fulfilling a request with another HTTP request, the service worker sets up the download and gets out of the way. With WebRTC in the mix, the Service Worker might want to, say, spend an hour constructing a large download from pieces from peers and stream it piece by piece into the response. There may be other parts of the spec that need to be revised to contemplate gigabyte-scale requests moving through nontrivial processing in the Service Worker before being saved to disk by the user agent.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1522