[whatwg] Device element and the lifetime of the stream objects

[Andrei Popescu]

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