Re: Direct assignment of MediaStream to <video> (Re: PROPOSAL: Use events instead of callbacks)

On 03/20/2012 01:29 PM, Stefan Hakansson LK wrote:
> On 03/16/2012 10:59 PM, Anant Narayanan wrote:
>> On Mar 15, 2012, at 12:48 PM, Travis Leithead wrote:
>>> * I'm not comfortable overloading the src property. This opens the
>>> door to a lot of weird discrepancies between content attribute src
>>> and IDL attribute src. I don't want to open the door to
>>> URL-accepting properties becoming extensible by other arbitrary
>>> specs. I think File API established the convention for this
>>> extensibility by creating the blob: protocol.
>>
>> If we decide to go ahead with URLS we have to deal with the
>> portability of strings. For instance, what happens if the web page
>> passes the URL to another web site, which the user then opens in a
>> different tab, where a video.src assignment is made?
>>
>> URLs now have to be tied to the origin to which they were issued and
>> the UA must enforce this. This is not a problem with URLs as they
>> exist today as possession of the URL implies access to the data (and
>> in the case of blob: the URL itself contains the data). This is not
>> true for MediaStreams - MediaStreams are transient, issued to only a
>> certain origin, and perhaps even just a tab.
>
> If I read the File API spec correctly ([1]), the URL created by
> "createObjectURL" would only be usable in the origin where it was created.
>
> I wonder if MediaStreams are really so different from blob's/file's (or
> Streams) that it would make sense to define another way. createObjectURL
> is after all an established and expected pattern, it seems natural to me
> to extend it to MediaStreams.
>
> [1] http://www.w3.org/TR/FileAPI/#originOfBlob

I assume Anant was talking about data: URLs (instead of blob: URLs) in 
his earlier remark about the URL containing the actual data. It used to 
be the case that possession of the URL implied access to the data, but 
that changed with blob:.

I agree with Stefan that, in the blob: URL case, refering to, e.g., a 
file on disk or to a data stream from a webcam may not be so different.

We've discussed this on public-webrtc as well some time ago. We didn't 
really come to any conclusion, but people seem to favor the approach of 
setting the MediaStream object directly. I think it's natural for new 
APIs to use the MediaStream object directly (e.g. PeerConnection's 
addStream() method), but I think we should stick with the 
createObjectURL()-approach for legacy APIs with DOMString src attributes 
for consistency.

/Adam

Received on Tuesday, 20 March 2012 12:59:01 UTC