Re: removing createObjectURL

On 2013-09-16 16:42, Harald Alvestrand wrote:
> 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.

This could be our starting point. We can always revisit this if we find 
that there are important use cases that suffers from not being able to 
send isolated streams/tracks.

>> 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.

Ok. Thanks for the update.

/Adam

Received on Tuesday, 17 September 2013 05:35:18 UTC