[whatwg] Device element and the lifetime of the stream objects
timeless at gmail.com
Wed Feb 16 06:27:19 PST 2011
On Wed, Feb 16, 2011 at 2:36 PM, Anne van Kesteren <annevk at opera.com> wrote:
> This is just a thought. Instead of acquiring a Stream object asynchronously
> there always is one available showing transparent black or some such.
> navigator.cameraStream. It also inherits from EventTarget. Then on the
> Stream object you have methods to request camera access which triggers some
> asynchronous UI. 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.
> It makes custom in-page UI harder, it does not prevent the need for
> scripting, and it does not help with fallback.
Yeah, I'd be quite happy to not have <device> at all.
> This is somewhat weird though :-)
that is much closer to how i'd want things to work. although from my
perspective, i don't know that we need to send many events. I don't
see a significant difference between a user with a camera covered by a
black tile, or a camera perpetually pointed at a white wall. If the
user wants to move where the camera points, that's up to the user, and
the app will notice that there's more data streaming.
I think it's sufficient for a UA to inform the user that <this page>
is streaming this <black region> and to allow the user to adjust the
"virtual camera" to point at something else, out through the fourth
wall at the user, out the window, at some other device, at a video
More information about the whatwg