Re: Proposed resolution for open items

On 5/12/2012 1:44 AM, Stefan Hakansson LK wrote:
> On 05/11/2012 09:50 PM, Randell Jesup wrote:
>> On 5/11/2012 2:25 AM, Stefan Hakansson LK wrote:
> ...
>>> "Direct assignment of MediaStream to Video": There was a lot of
>>> discussion. There seem to be a consensus that assignment via
>>> "createObjectURL" must be supported (since this is an established
>>> model). Due to this, and to that there does not seem to be consensus 
>>> for
>>> direct assignment, the chairs propose that direct assignment should be
>>> postponed to later versions
>>
>> This is unfortunate for different reasons; Robert's concern is that
>> (IIRC) that streams for which you've called createObjectURL are
>> complicated to properly resource track and can lead to unrecoverable
>> resource leaks (createObjectURL() and then never assign it anywhere, for
>> example).
>
> (Speaking as contributor) This has been discussed quite a bit in the 
> WebApps WG (as createObjectURL is used to reference blobs). The 
> solution adopted as I understand it includes well defined life time 
> handling and that the URI can be used only once in the default case.

The default case seems to be it lives for the life of the document, or 
until revoke.  You can optionally make it one-use-only.

Wow.  What a complex system for managing references in order to make it 
manipulable in URI/string land.  It brings to mind "well, I've got this 
hammer...."  Basically this adds extra boilerplate all over, and some 
complexity layers to handle the URI aspect.  And if someone forgets the 
oneTimeOnly bit, then the resource is likely to be left locked until the 
document is destroyed.

> Would the same solutions not work when createObjectURL is used to 
> reference MediaStreams?

God I hope that the API for createObjectURL is the same for all objects, 
or we *REALLY* have a mess, so it had better work.  I'd love to be using 
src and not be stuck with the createObjectURL requirements, but I 
realize that's not likely; so my next hope was to make normal uses of 
MediaStreams never need createObjectURL (PeerConnection for example 
doesn't use ObjectURLs, why should other things?)  We'll now have 
developers directly using MediaStreams 
(peerconnection.AddStream(stream)), and indirect URL use via 
createObjectURL (video.src = createObjectUrl(stream, 
{onetimeonly:true});) all in the same script.  Yes, it will work, but I 
don't think it's a good design and will encourage resource leaks (and 
ones that grab exclusive use of single-instance resources like cameras - 
it's not like a file blob or memory leak).|

|
> http://dev.w3.org/2006/webapi/FileAPI/

-- 
Randell Jesup
randell-ietf@jesup.org