Re: Selecting Bluetooth Adapters

Hi Luis,

  Indeed we had this discussion (issue #22) last October, and ended-up saying exposing adapters looks like over-engineering. What's more, Scott raised the good point of eventually multiple apps messing-up with adapters..

  If we decide to go up to adapter level, I'd advise to expose a wording like current or default adapter, so as to align with the fact there is potentially not just one.

Kind Regards,
Julien

> Le 23 mars 2015 à 21:37, Von Dentz, Luiz <luiz.von.dentz@intel.com> a écrit :
> 
> 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 Tuesday, 24 March 2015 22:03:40 UTC