Re: Selecting Bluetooth Adapters

While true, the reality is that Chrome OS doesn't offer the ability to
address multiple adapters and as far as I know, OS X doesn't either

On Mon, Mar 23, 2015 at 1:37 PM Von Dentz, Luiz <luiz.von.dentz@intel.com>
wrote:

> 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/1BKBY39CeUWzkmEExTml0JUEy2eHD4
> upixt1_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
> >>> >>
> >>>
> >>
> >
>