- From: Andrei Popescu <andreip@google.com>
- Date: Wed, 16 Feb 2011 16:35:03 +0000
Hi Anne, On Wed, Feb 16, 2011 at 12:36 PM, Anne van Kesteren <annevk at opera.com> wrote: > On Tue, 15 Feb 2011 17:48:24 +0100, Leandro Graci? Gil > <leandrogracia at chromium.org> wrote: >> >> All feedback will be greatly appreciated. > > This is just a thought. Instead of acquiring a Stream object asynchronously > there always is one available showing transparent black or some such. E.g. > navigator.cameraStream. It also inherits from EventTarget. Then on the > Stream object you have methods to request camera access which triggers some > asynchronous UI. I thought we were all trying to avoid asynchronous UI (dialogs, infobars, popups, etc), which is a solution that does not scale very well when many different APIs require it. This was one of the main reasons for trying a different approach. > Once granted an appropriately named event is dispatched on > Stream indicating you now have access to an actual stream. When the user > decides it is enough and turns of the camera (or something else happens) > some other appropriately named event is dispatched on Stream again turning > it transparent black again. > > This also removes the need for the <device> element as has been mentioned > off-list. Basically, the idea was that <device> does not really help anyone. What do you mean exactly by this? The usecases are pretty clear. > It makes custom in-page UI harder, it does not prevent the need for > scripting, and it does not help with fallback. > I was never under the impression we need to prevent the need for scripting. Why is that a goal? > This is somewhat weird though :-) > Agreed. And, as I said earlier, I thought the goal was to try something else than asynchronous permission dialogs. What has changed? Thanks, Andrei
Received on Wednesday, 16 February 2011 08:35:03 UTC