- From: Jim Barnett <Jim.Barnett@genesyslab.com>
- Date: Tue, 8 May 2012 08:53:42 -0700
- 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 timeout. 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 not). (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 Tuesday, 8 May 2012 15:54:33 UTC