Scope of requestDevice(), Re: Notes from meeting between Chrome and Mozilla folks

On Sunday, August 10, 2014 at 2:41 PM, Jeffrey Yasskin wrote:

> On Fri, Aug 8, 2014 at 2:51 PM, Vincent Scheib <scheib@google.com (mailto:scheib@google.com)> wrote:
> > I agree on the 2 points:
> > - Need a way to accept UUID per Bluetooth spec for non standard services
> > - Identifying standard services via their name vs full or short UUID makes
> > sense. Let's do functionName("standard_gatt_service_name")
> 
> 
> 
> This email is somewhat rambly and lacking in conclusions. Sorry about that.
> 
> Overloading functions like requestDevice to take either
> "standard_gatt_service_name" or propietary_uuid should work, but folks
> have seemed hesitant to use overloading in other specs. We can't
> cleanly use navigator.bluetooth.requestDevice([{services:
> [navigator.bluetooth.lookupStandardGattService("standard_name")]}])
> because that's no shorter than
> navigator.bluetooth.requestDevice([{services:
> [navigator.bluetooth.services.standard_name]}]) (while
> navigator.bluetooth.requestDevice([{services: ["standard_name"]}]) is
> shorter)
> 

(Sorry for snipping your email a bit short, I want to come back to the rest of your email after we sort out the following...)

Before we even do anything with custom UUIDs or strings equivs., I think it's critical to talk about just requesting access to a bt device. It feels to me that providing the `services` arguments can only ever serve as a hint to the user agent: the user would then be presented with a list of devices, but what is to say that the browser UI won't allow them to select other bt devices to choose from (as all OSs do today). 

I.e., being up to the user, these two calls would potentially yield the same result: 
navigator.bluetooth.requestDevice()

navigator.bluetooth.requestDevice({services: [...]})


Let's consider that at any one time, there is going to be an extremely limited number of devices to choose from in the user's (physical) range. This will also exclude keyboards, mice, audio-related devices, etc. - so likely there will be like 1 or 2 devices - and the choice made by the user will correspond to the activity afforded by the web application they are using: that is, I'm using `running.com` and I obviously want to connect my `heart rate monitor`. So, trying to use {services: []} when making the first request only buys you a little bit of filtering - and it's not really all that helpful. 

If we were to say that requestDevice({services: [...]}, MUST match the services, that would (unfairly - even if accidentally) discriminate/exclude hardware. If that was the case, then it's pretty likely we (as a browser) would ignore the filtering hint and just allow users to pick the device they want to connect. 

At the moment, here on the list we seem to be mixing up the protocols that a particular peripheral uses (expressed as UUIDs that represents "service" and so on) and the capabilities of a bt device. I'm definitely no expert in BT, but, to me, that doesn't feel like the right way to model this problem.

Received on Sunday, 10 August 2014 22:09:51 UTC