Re: [web-bluetooth] optionalServices is not very clear

The idea for `optionalServices` is that it lets the UA know the 
complete set of services a website wants to use. This will let us give
 the site an early error if it intends to access a disallowed service,
 and could eventually let us include a description of exactly what the
 site wants to do with the selected device in the `requestDevice` 

Only the `filters` affect the set of devices shown in the dialog. Both
 the `filters` and `optionalServices` determine the [allowed services 

`filters` is a sequence of sequences because a site might be able to 
use several different kinds of devices, so we need some way of saying 
"I need a device that supports {X and Y} or that supports {Z and W}".

We could add `optionalServices` to the filter: it would let a site say
 "for devices that have these services, I can also take advantage of 
these other ones" instead of just listing all the extra services the 
site can take advantage of. This would complicate the assignment to 
the _allowed services list_, since we'd need to say what to do for 
devices that support all of X, Y, Z, and W when their optional 
services are different. Do we grant access to the union? How would 
that look in a UI? It seemed simpler just to put the whole set of 
services in a single bag.

I have been thinking of combining the two arguments into a single 
dictionary. `requestDevice([{services: [x, y]}], {optionalServices: 
[a, b]})` makes it easy to put things in the wrong set of brackets. 
`requestDevice({filters: [{services: [x, y]}], optionalServices: [a, 
b]})` might be easier to read and write.

GitHub Notif of comment by jyasskin

Received on Monday, 23 March 2015 15:51:44 UTC