Re: On reserving and releasing resources

On May 8, 2012, at 8:06 AM, Stefan Hakansson LK wrote:

> Basically getUserMedia can have two different meanings:
> 
> 1. It is merely a way for the user to give consent to the application to use devices (and the user is involved in selecting which devices). The devices would not be reserved, activated or start producing data until there is a consumer (e.g. a video element) for the MediaStream delivered by getUserMedia.
> 
> 2. It is rather a way to grab those resources, activate them and have them start producing data (regardless of whether the data is consumed or not).

Regardless of what it is (and I always assumed it was 2), we need the API to provide a function to do 2. Otherwise you can't make apps that don't get their resources stollen. I'm not sure we need an API that provides 1 but perhaps we do. 

> 
> (I'm sure there are also other interpretations).
> I think that these aspects have not been discussed very much, but they have big implications.
> 
> For example, if we assume meaning 2. above, an application could not be written to do getUserMedia at load time (to have that done if/when there is a need to use the MediaStream) as this would block other applications from using e.g. camera and mike.
> 
> On the other hand, if we assume meaning 1., the situation could be that once the application needs the MediaStream, the devices are blocked by another application (which is using e.g. camera and mike), so there would be an error even though getUserMedia worked out OK.
> 
> I also think it has implications on when to release devices. With meaning 1., it would probably make sense to release devices once there are no consumers of the MediaStream(s) they generate. With meaning 2., devices should probably be released only if the user revokes (via the browser chrome) the consent to use them or if all MediaStream's that the device delivers to have "ended" (by the app calling the "stop" method).
> 
> I think it would make sense to spend a little while discussing this tomorrow (and on this list!).
> 
> Br,
> Stefan
>

Received on Thursday, 17 May 2012 19:03:52 UTC