Selecting Bluetooth Adapters

I'm splitting this from the security thread because I don't see a
security aspect in adapter selection.

I mentioned the adapters question in
https://github.com/WebBluetoothCG/web-bluetooth/issues/22#issuecomment-57359185:
I'm not sure it makes sense to expose separate adapters to websites.
At the moment, the UA simply knows how to communicate with Bluetooth
devices in its vicinity, using whatever adapters its machine exposes,
and we don't expose the complication of picking an adapter to the web
page. If we need to in the future, we should be able to add that in a
backward-compatible way.

Re the scheme for selecting devices and services, check out
requestDevice() in
https://webbluetoothcg.github.io/web-bluetooth/#device-discovery and
the getPrimaryService method in BluetoothDevice:
https://webbluetoothcg.github.io/web-bluetooth/#idl-def-BluetoothDevice.
(Note, this is probably going to move to a new class once
https://github.com/WebBluetoothCG/web-bluetooth/pull/73 is reviewed.
Please comment there if you're interested.)

On Thu, Mar 19, 2015 at 2:47 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
> Hello,
>
> As an additional issue, I would like to ask how do we handle selecting
> one from possibly multiple adapters.
> There are two basic choices:
> 1. enumeration + management of adapter id’s (e.g. BT address or
> mappings to opaque id’s).
> e.g. Promise<sequence<BluetoothAdapter>>  requestAdapters();
>
> 2. encapsulated by a dialog or selection algorithm managed by the UA
> e.g. Promise<BluetoothAdapter>  requestAdapters();
> where the UA decides whether to take a dialog with the user, or use an
> algorithm in order to select an adapter.
> In addition, we need a property ‘selectedAdapter’ (can be null) and
> and event ‘onadapterchanged’.
>
> Based on experience so far, we'd prefer option 2. This has also been
> used in the Presentation/Second Screen API [1], and it's useful in
> that it does not need to expose adapter id's to web pages, only a
> selected object. Of course, this applies mainly for use cases with a
> single selection (lists are also manageable with some added
> complexity).
>
> A similar scheme could also be used with devices, and services.
> For instance, we could use a
> Promise<BluetoothGATTService> getPrimaryService(BluetoothServiceUuid service);
> method for retrieving the primary service (the UA decides the policy
> on how exactly to do that),
> and in addition, we need events for serviceadded, serviceremoved, and
> servicechanged.
>
> [1] http://w3c.github.io/presentation-api/
>
> Best regards,
> Zoltan

Received on Thursday, 19 March 2015 22:20:55 UTC