Make WebRTC usable as a backend for Service Workers to fulfill requests from a peer-to-peer network

[interfect]

The long-lived #230 does not quite capture one of the things that people are looking for from the WebRTC API, which is to be able to use it to back the resource-serving capabilities of Service Workers with a peer-to-peer network.

See for example:

• Add support for WebRTC Data Channel in Workers #230 (comment) (which is just me asking for this)
• Add support for WebRTC Data Channel in Workers #230 (comment)
• Make RTCDataChannels Transferable #317 (comment)
• Make RTCDataChannels Transferable #317 (comment)

I'm proposing a couple changes to make this work, only one of which is really part of the WebRTC spec itself:

1. Expose the whole WebRTC API to all forms of Worker.
2. Specify that as long as an open tab is associated with a ServiceWorker, the ServiceWorker should stay alive and be able to handle events.

Change 1 looks to consist, on the spec side, of just changing [Exposed=Window] to [Exposed=(Window,Worker)] on all of the types. That's how IndexedDB, which is available from both pages and workers, appears to do it. But there would also presumably need to be some suggestion of how the WebRTC events are expected to affect service worker lifetime. My suggestion would be to say that workers are allowed to be terminated in the middle of handling events from peers. This might require minor revisions to the service worker spec which currently prohibits terminating a service worker that has an event to handle except in cases of user-agent-defined abnormal operation, of which "getting lots of events from peers" is probably not a good example.

Change 2 is probably entirely within the Service Worker spec's section on service worker lifetime.

[alvestrand]

I think this needs to be considered as an extension, given the sate of play of WebRTC.
Please ask it in the NV repo.

[interfect]

@alvestrand You mean https:/w3c/webrtc-nv-use-cases right?

[alvestrand]

Yes. Thanks for filing, closing here.