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

>From: Harald Alvestrand [mailto:harald@alvestrand.no]
>Sent: Tuesday, March 13, 2012 11:06 PM
>
>On 03/13/2012 07:44 PM, Travis Leithead wrote:
>>> -----Original Message-----
>>> From: Anant Narayanan [mailto:anant@mozilla.com]
>>>
>>> As Adam correctly points out subsequently in the thread, chaining and
>>> bubbling don't really make sense for getUserMedia. However, they do make
>>> sense for a MediaStream (which could be attached to a<video>  or
>>> <canvas>, and may want to bubble events back into the parent). Thus, if
>>> we add events to MediaStream, I think there's a good case for having
>>> them be real events. At that point, it's only a matter of consistency
>>> for having getUserMedia behave in a similar manner.
>> You don't attach a MediaStream to a<video>  or<canvas>. (Yes, I know Rich
>> proposed the direct-assign technique, but I'm not in favor of that
>approach
>> for a number of reasons.)
>
>Forking the thread - do you care to share those reasons?

(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.
* createObjectURL is an established and expected pattern (via FileAPI [3]) for 
  binding back-end data with various elements. Extending the existing pattern 
  seems more appropriate than minting a new direct-assign approach. Furthermore,
  the recently adopted Stream API [4] will use the createObjectURL as well, and
  would further confuse folks if a "Stream" API used createObjectURL, but a 
  "MediaStream" used an entirely different model.
* 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.

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] http://lists.w3.org/Archives/Public/public-media-capture/2011Dec/0059.html
[2] http://lists.w3.org/Archives/Public/public-media-capture/2011Dec/0077.html
[3] http://dev.w3.org/2006/webapi/FileAPI/
[4] http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
[5] http://people.opera.com/richt/release/specs/device/o-device.html#stream-mode-behavior

Received on Thursday, 15 March 2012 19:48:50 UTC