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

Re: Selecting Bluetooth Adapters

From: Von Dentz, Luiz <luiz.von.dentz@intel.com>
Date: Mon, 23 Mar 2015 22:37:44 +0200
Message-ID: <CACumGOK3QvwQDPgeprcsTKGK4-7Hf=fqbscTBaF+YsxG2tPORQ@mail.gmail.com>
To: Scott James Remnant <keybuk@google.com>
Cc: Vincent Scheib <scheib@google.com>, Jeffrey Yasskin <jyasskin@google.com>, "Kis, Zoltan" <zoltan.kis@intel.com>, public-web-bluetooth <public-web-bluetooth@w3.org>
Hi Scott,

I agree it is kind of special case not to use the default, but in case
of peripheral it allows choosing which adapter to use to advertise.
Anyway we can probably wait to see how things evolves.

On Mon, Mar 23, 2015 at 6:45 PM, Scott James Remnant <keybuk@google.com> wrote:
> I'm with Vincent here, at the point a web application is trying to say "no,
> I don't want the default system Bluetooth Adapter, I want another one" I'm
> starting to think it's trying to play silly buggers.
>
> Scott
>
> On Fri, Mar 20, 2015 at 10:53 AM Vincent Scheib <scheib@google.com> wrote:
>>
>> Luiz, would you help educate me regarding why a peripheral would like to
>> control which adapter is being used? My imagination is having a hard time
>> thinking of multi-adapter devices and how they work differently.
>>
>> On Fri, Mar 20, 2015 at 10:24 AM, Jeffrey Yasskin <jyasskin@google.com>
>> wrote:
>>>
>>> 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
>>> https://github.com/WebBluetoothCG/web-bluetooth/issues/78.
>>>
>>> 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 Monday, 23 March 2015 20:47:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 March 2015 20:47:31 UTC