- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 10 Apr 2018 14:16:57 +1000
- To: Isaac Kwan <i@isaac.pw>
- Cc: public-webrtc@w3.org
FWIW, the concerns about IDP aren't real, as far as I can see. You might need a frame to complete the flow, but those can be created from workers. On Tue, Apr 10, 2018 at 1:25 PM, Isaac Kwan <i@isaac.pw> wrote: > As a web developer (so take what I said with a grain of salt), it > seems to me that the easier way to implement this is to allow > creations of a restricted subset of PeerConnections in workers. > > In particular, > - Said PeerConnections are only started and available to the worker > - IdP-related functions (which are not implemented in Chrome anyway) > are not available > - addStream() can optionally be available, but navigator.mediaDevices > would not be exposed to workers > > I am not aware of any UI interaction requirements for > DataChannel/PeerConnection for now... but in case there are any, they > can be share the same permission set as their origin. > In particular: if a permission is granted to web pages of the same > origin, grant it automatically to its workers too; otherwise, reject > the request gracefully. (Smart developers would then request relevant > permissions before having the worker to do anything sensitive.) > > The advantages are: > - No need to handle atomic transfer of DC/PC ownership, cross-scope > bookkeeping (upstream PC closes -> DC in workers get terminated) etc. > - Greater flexibility - If downstream applications requires > transferring a PeerConnection / DataChannel to a worker (e.g. IdP > constraints), downstream application can do their own signaling > > On 10 April 2018 at 05:57, Martin Thomson <martin.thomson@gmail.com> wrote: >> On Tue, Apr 10, 2018 at 4:16 AM, westhawk <thp@westhawk.co.uk> wrote: >>> On 9 Apr 2018, at 19:04, youenn fablet <yfablet@apple.com> wrote: >>> >>> I would favor enabling instantiations of PeerConnection in workers. >>> It seems particularly useful in ServiceWorker contexts where the link with a >>> particular Document may be broken at any point. >>> If we have that, there might be little incentive in transferring data >>> channels. >>> >>> >>> That would be nice, but there are a bunch of user interaction requirements >>> that may make that tricky, >>> - Getting local IP addresses requires a user to grant media permissions. >>> - Authenticating an ID requires a user interface >>> - starting a media stream requires a user click >>> >>> That’s just off the top of my head. I suspect more would be found if one >>> looked hard. >>> >>> I have the feeling that transferring a connected DataChannel over a >>> postMessage may be >>> more of a quick win. >> >> For me, the lifecycle of a ServiceWorker is the biggest hurdle. >> >
Received on Tuesday, 10 April 2018 04:17:34 UTC