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` 
dialog.

Only the `filters` affect the set of devices shown in the dialog. Both
 the `filters` and `optionalServices` determine the [allowed services 
list](https://webbluetoothcg.github.io/web-bluetooth/#dfn-allowed-services-list).

`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
See 
https://github.com/WebBluetoothCG/web-bluetooth/issues/82#issuecomment-85059258

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