W3C home > Mailing lists > Public > public-web-bluetooth@w3.org > March 2015

Re: Selecting Bluetooth Adapters

From: Jeffrey Yasskin <jyasskin@google.com>
Date: Fri, 20 Mar 2015 10:24:21 -0700
Message-ID: <CANh-dXm3kF2=bW5CY=SMBGeSomLKSAfmXwkQcu0C8JBPYsMQzQ@mail.gmail.com>
To: "Von Dentz, Luiz" <luiz.von.dentz@intel.com>
Cc: "Kis, Zoltan" <zoltan.kis@intel.com>, public-web-bluetooth <public-web-bluetooth@w3.org>
Good point, thanks. I've added a note about exposing adapters for
peripherals to https://docs.google.com/document/d/1BKBY39CeUWzkmEExTml0JUEy2eHD4upixt1_7zqjMkg/edit,
which is now linked from

On Fri, Mar 20, 2015 at 7:09 AM, Von Dentz, Luiz
<luiz.von.dentz@intel.com> wrote:
> Hi Jeffrey,
> Perhaps right now it doesn't really add anything since apparently the
> instanceId can be used to differentiate the same device in different
> adapters, in case the UA decide to discover in all adapters for
> example. In the other hand for peripheral role it may be a good idea
> to have the adapter as an optional parameter when advertising, but
> perhaps you don't want to add any API related to peripherals right
> now.
> On Fri, Mar 20, 2015 at 12:20 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>> 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 Friday, 20 March 2015 17:25:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:53 UTC