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

On Mar 15, 2012, at 12:48 PM, Travis Leithead wrote:
> (For context: this is in relation to Rich's email last December [1])
> I illustrated some of my reasons in a response to Rich's mail [2]. To further 
> elaborate:
> * I wouldn't want to support direct-assign AND createObjectURL - I'd rather prescribe 
>  only 1 approach to avoid confusing users; also makes it easier to polyfill.

+1.

> * 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. Translating these requirements to a URL feels rather clunky to me, and are best represented as objects (that are not by their very nature, portable).

> Specifying the "streaming behavior" as is noted in [5] is very important; I
> strongly support that, and I think it needs to happen irrespective of whichever 
> "binding" approach is used for media elements.

+1. roc's proposal for MediaStreamProcessing (https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html) has ideas in similar vein.

-Anant

Received on Friday, 16 March 2012 22:00:07 UTC