W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2016

Re: Query (not a bug): Device selection - should permissions matter?

From: Joe Berkovitz <joe@noteflight.com>
Date: Tue, 16 Feb 2016 08:48:52 -0500
Message-ID: <CA+ojG-b5zpoaDyybtKV2i2P=6NS0wMvBWbSy6iHM78Dp3tRzGw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
I think the answer depends on where things stand with an application's
ability to enumerate user-readable names of devices and present them to the
user, prior to selecting one of them.

If enumerateDevices() is still not assured of some way to acquire this
information (possibly with some permission grant involved) then "1" makes
the most sense to me.

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC

+1 978 314 6271

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Tue, Feb 16, 2016 at 7:53 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> When thinking about how to make a more formal permission handling for
> mediacapture-main, I wonder about how permission status should influence
> selection.
>
> Let's think about an UA with 3 attached cameras:
>
> A has a "granted" permission
> B has no permission, so will be prompted for if selected
> C has permission "denied".
>
> If I select with constraints that allow either to be selected, what
> should happen?
>
> Three possibilities I see:
>
> 1 - Spec says "disregard C, pick between A and B at UA's choice" (prompt
> if you feel like it)
> 2 - Spec says "choose B; if that's unsuitable prompt for A" (prefer
> permitted)
> 3 - Spec says "this is not a spec matter, UA will do what it wants" (no
> guidance)
>
> All of these can be written as normative requirements or "implementation
> suggestions".
>
> At the moment, the spec is roughly "1" (step 3 can be seen as skipping
> "denied" devices).
>
> What do people think?
>
>
>
>
>
>
Received on Tuesday, 16 February 2016 13:49:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 February 2016 13:49:23 UTC