- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 16 Sep 2013 16:42:38 +0200
- To: public-media-capture@w3.org
On 09/16/2013 03:32 PM, Adam Bergkvist wrote: > On 2013-09-13 19:57, Martin Thomson wrote: >> On 12 September 2013 22:33, Adam Bergkvist >> <adam.bergkvist@ericsson.com> wrote: >>> In addition to transferring objects with postMessage()'s third >>> argument, you >>> can send certain objects (File, FileList, Blob, ...) as the first >>> "message" >>> argument (of type any) [1]. Objects sent that way are cloned, not >>> transferred, and are still usable on the sending side after being sent. >> >> I guess that I could live with that, if you could convince me that >> this isn't going to be a problem for people who create a MediaStream >> with exclusive access to the source. We haven't enacted that >> constraint yet, but it keeps coming up. > > From what's in the spec regarding isolated streams/tracks I can see > the following options (no order of preference): > > 1) Not allow a stream/track with isolation constraints to be sent with > postMessage(). I think that makes sense. > > 2) Since isolation, according to the spec, is about limiting the use > of a track to rendering and sending it to a specified peer, the same > rules could apply at the receiver. A step further would be to only > allow rendering. The last note I got from EKR said that he and Martin had concluded that "noaccess" was only meaningful if it meant "can't be added to a PeerConnection" - which means it's only useful for the hair check. He has promised to propose new language for the constraint descriptions. > > /Adam >
Received on Monday, 16 September 2013 14:43:07 UTC