Re: removing createObjectURL

On 2013-09-03 18:44, Martin Thomson wrote:
> On 2 September 2013 04:19, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> There are other solutions (e.g. making MediaStream transferable) to this
>> issue available, but we'd have to spec that out in that case.
>
> I'd be interested in seeing what that took before coming back to this decision.

I don't thing it would be that much that needs to be specced up. I can 
think of the following:

1. We need to define neutered for MediaStream, and what happens if the 
app tries to use the neutered MediaStream (throw ""NOT_FOUND_ERR"?).

2. We need to decide what happens for consumers of a MediaStream if it 
is neutered while being consumed (silence/blackness has been proposed) 
and what the srcObject returns if the source was neutured ("NotFoundError"?)

3. We need to specify the actual cloning+transfer algorithm. But I think 
we can use the built in cloning of MediaStream with some added wording 
("To transfer a MediaStream object old to a new owner owner, a user 
agent must clone the old object with the clone being owned by owner, 
thus obtaining new, must neuter the old MediaStream, and must finally 
return new.").

4. We need to add "MediaStream implements Transferable"

But the difficult parts would probably be handling corner cases related 
to access, and revocation of access, to input devices. What happens e.g. 
with the hot indicator in the tab if the tab that did getUserMedia 
transfers the stream to another tab? And which tab is responsible for 
revoking access to the input devices?

I'll note that CreateObjectURL satisfies the use cases, and that the 
Editor of File API has offered hooks so that we need not to specify it. 
Perhaps that is the way to go?

>
> I am also interested in the ability to transfer other things
> (RTCPeerConnection might be an interesting option...)

As far as I can understand, this would actually be simpler to handle.

>

Received on Wednesday, 4 September 2013 12:40:17 UTC