W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2012

RE: On reserving and releasing resources

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Tue, 8 May 2012 08:53:42 -0700
Message-ID: <E17CAD772E76C742B645BD4DC602CD81062912E2@NAHALD.us.int.genesyslab.com>
To: "Stefan Hakansson LK" <stefan.lk.hakansson@ericsson.com>, <public-media-capture@w3.org>
In definition 1, 'getUserPermission' might be a better name for the
function.  In that interpretation, permission is separate from
possession of the device, and it would make sense for the permission to
persist even once the devices were released (because they weren't being
used at the moment).  Though it might be odd for the app to suddenly
turn on the camera 30 minutes after the user gave a permission that he
has long since forgotten about.  So maybe there would need to be a

I think that tying permission and possession of the device (your
definition 2) is a simpler model, and easier to understand.  On the
other hand, it's less flexible.  

- Jim

-----Original Message-----
From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Tuesday, May 08, 2012 10:07 AM
To: public-media-capture@w3.org
Subject: On reserving and releasing resources

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

(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!).

Received on Tuesday, 8 May 2012 15:54:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC