Re: Proposal for output device selection

my two cents

On Fri, Aug 16, 2013 at 4:15 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Aug 16, 2013 at 11:18 AM, Martin Thomson <martin.thomson@gmail.com
> > wrote:
>
>> You did, but that's not the same as having the application able to
>>  manage those choices over time.  The problem with having the UA do
>> this is that it is often ignorant of application context.  It can even
>> have difficulty identifying a specific application.  The same origin
>> can host multiple applications, or the one application can appear on
>> multiple origins.
>>
>
> "One application at multiple origins" is not supported by the Web
> platform. Features like persistent storage, application cache and
> remembered permissions don't handle that case. This is not something we
> should be trying to support.
>
> Usually a page URL (excluding query parameters and fragment reference) is
> adequate to identify an application.
>
> From an application developer perspective, I don't trust the UA to get
>> this right.
>>
>
> In the long run the number of UAs is much smaller than the number of
> applications, and a lot of the application developers will not be
> competent, so placing responsibility on the UA generally works out better,
> all other things being equal.
>

Sorry to paraphrase, but it sounds like there are two assumptions and
conclusions based on them:

1) Application developers will be incompetent for the most part so let's
not give the competent ones power.
2) Having the UA do things instead of the application is generally better.

If that's the gist, then I don't agree with the conclusions.  If anything,
we've been going in exactly the opposite direction for the past few years.


> In this case, even good developers will have great difficulty anticipating
> the range of hardware and devices that UAs deploy on, let alone testing
> across that range.
>

The range of hardware and devices is the same regardless of whether the UA
owns device selection or the application.
The difference will be that in the non-virtual case, the app developers
will have some idea about the devices they're testing on, in the virtual
case they will have no idea.

Making the API "just work" with the range of devices falls on UA developers
in either case.


> Security and privacy are also much easier to handle in the UA since we can
> trust the UA and not the application.
>

AFAIK the idea is to continue to let the UA handle permissions.


> Any kind of device enumeration creates privacy issues which a "logical
> output device" approach simply doesn't have.
>

Can you clarify exactly what privacy issues you're thinking of?  There are
pros and cons on both sides so it's easier to discuss specifics to see if
things are solvable or not.

The 'logical output device' approach sounds more complex to me since
there's an extra layer where things can get screwed up.  I also think that
relying on the user to properly set up the mapping of virtualized audio
devices to physical ones, is a slippery slope to go down.  As Harald points
out, the web application is much more likely to be able to do the right
thing if it has knowledge about devices (assuming any privacy issues can be
addressed).


> Rob
> --
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
> waanndt  wyeonut  thoo mken.o w  *
> *
>