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

Re: Selecting Bluetooth Adapters

From: Scott James Remnant <keybuk@google.com>
Date: Mon, 23 Mar 2015 16:45:03 +0000
Message-ID: <CAHZ1yCk01EP1xkU-_iwO7Z6mH87jCWUKsD948wgMTRLWsXfNhA@mail.gmail.com>
To: Vincent Scheib <scheib@google.com>, Jeffrey Yasskin <jyasskin@google.com>
Cc: "Von Dentz, Luiz" <luiz.von.dentz@intel.com>, "Kis, Zoltan" <zoltan.kis@intel.com>, public-web-bluetooth <public-web-bluetooth@w3.org>
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 16:45:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 March 2015 16:45:32 UTC