Re: Selecting Bluetooth Adapters

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 12:21:22 UTC