W3C home > Mailing lists > Public > public-web-bluetooth@w3.org > August 2014

Re: Notes from meeting between Chrome and Mozilla folks

From: Jeffrey Yasskin <jyasskin@google.com>
Date: Sun, 10 Aug 2014 11:41:24 -0700
Message-ID: <CANh-dXkzg5yb9tAum9YzwvfFpaVqANjr0nBBw-cS4G8ZSyMPRA@mail.gmail.com>
To: Vincent Scheib <scheib@google.com>
Cc: Shawn Huang <shuang@mozilla.com>, public-web-bluetooth <public-web-bluetooth@w3.org>, Marcos Caceres <marcos@marcosc.com>
On Fri, Aug 8, 2014 at 2:51 PM, Vincent Scheib <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)

The current spec draft includes a UUID type
(http://webbluetoothcg.github.io/web-bluetooth/#uuids), but we could
overload between string formats instead, or define a NamedUUID that
would help debugging by giving the folks developing against a
proprietary API some way to include a human-readable name. We could
also add a registry system to let folks define their own names for
proprietary UUIDs.

When navigating the Service/Characteristic/Descriptor hierarchy, the
spec draft doesn't yet define a "findCharacteristic" function that
could take a symbolic characteristic name. Like the
chrome.bluetoothLowEnergy API, it currently requires users to iterate
over all characteristics and test whether the UUID matches what
they're looking for. To support symbolic names, we'd need to add a
'symbolicName' field next to the 'uuid' field. We could add the
findCharacteristic function instead, but that'll rule out services
that contain two instances of the same characteristic. I've had a hard
time pinning Bluetooth folks down on whether that can happen in sane
devices.

It probably makes sense to file an issue or two at this point. I'll
get to this tomorrow morning if nobody else has yet.

Jeffrey
Received on Sunday, 10 August 2014 18:42:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:38:27 UTC