[whatwg] Stream API Feedback

[Philip Jägenstedt]

On Thu, 17 Mar 2011 16:48:40 +0100, Olli Pettay <Olli.Pettay at helsinki.fi>  
wrote:

> On 03/17/2011 03:11 PM, Lachlan Hunt wrote:
>> On 2011-03-16 19:29, Olli Pettay wrote:
>>> Perhaps navigator.getUserMedia("audio,video", success, error);
>>> could return an url to the device in the success callback, and that url
>>> could be then set to video.src.
>>
>> The creation of a URL is unnecessary indirection. It's easier to avoid
>> creating special URLs entirely, and instead assign the the Stream object
>> directly to video.src.
>
>
> The type of .src is string.
> Assigning a different type of object to it
> is quite strange.
>
> Also, if getUserMedia would return just an URL, browser wouldn't need
> to create any stream object (unless someone then want to stream
> from <video> to PeerConnection).

Sure, but instead one would have to mint URLs and keep a mapping between  
those URLs and the streams that they actually represent. If people copy  
those URLs around, how long are they supposed to work for? Consider this  
scenario:

function getStreamURL() {
   var s;
   // code that sets s to a new Stream object for the default camera or  
something
   return s.url;
}
var url = getStreamURL();
/* garbage collector? */
document.querySelector('video').src = url;

Does this break randomly depending on when the garbage collector runs, or  
is the returned string somehow magical so that it actually keeps the  
stream alive?

>> ... src property definition needs to be changed
>> from DOMString to any.
>
> That would be strange and make API inconsistent with <img> and <iframe>  
> for example.

<video> is already very different to <img> and <iframe> in that it also  
has child <source> elements and a currentSrc attribute. What's the  
practical harm in allowing video.src setter take an object?

-- 
Philip Jägenstedt
Core Developer
Opera Software