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

On Sun, Aug 10, 2014 at 3:09 PM, Marcos Caceres <marcos@marcosc.com> wrote:
>
>
> 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...)

No problem. :)

> 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.
>

If a website doesn't speak the same language as the device, it doesn't
seem like it matters what capabilities the device has; the website
won't be able to talk to it to take advantage of them. The
language/protocol is named by the service UUID.

It's a little like a program that knows how to decode .pngs. If the
browser lets the user select a .jpg, the site is just going to have to
fail when trying to parse the file. There's not even much possibility
that the device just selected the wrong "extension" in this analogy.
If the device exposes an unexpected service UUID, but the browser maps
that to the expected one (but which of the several exposed UUIDs needs
to be mapped?), the website still needs to navigate the
characteristics by their UUIDs, which also won't match.

Jeffrey

Received on Monday, 11 August 2014 13:17:03 UTC