Re: Notes from meeting between Chrome and Mozilla folks

On August 8, 2014 at 1:59:06 PM, Vincent Scheib (scheib@google.com) wrote:
> On Thu, Aug 7, 2014 at 11:38 AM, Marcos Caceres wrote:
> The way to communicate succinctly what to communicate with is the service
> UUID https://developer.bluetooth.org/gatt/services/Pages/ServicesHome.aspx

Ok, let's take a step back for a sec. (we can deal with the UUID thing separately). Do you agree that, from that page, that the following string is redundant as it is repeated over and over?

"org.bluetooth.service."

Particularly in contexts where you know that you are requesting a service. 

Secondly, do you agree that any random opaque string could be substituted for the assigned number?

That is:
org.bluetooth.service.alert_notification = 0x1811

In terms of uniqueness, how is the above any better than:
"alert_notification" = "alert_notification" 

or, in Web IDL terms:

```
enum BluetoothService{
  "alert_notification"
};

interface BluetoothThing{
  void doSomething(BluetoothService service);
  attribute BluetoothService type;
  attribute sequence<BluetoothServices> characteristics; 
};
```

Where in JS:

var x = new BluetoothThing()
x.doSomething("alert_notification")
//returns human friendly string
console.log(x.type)
//returns human friendly strings
x.characteristics; 

> Otherwise one would fall to some type of 'duck typing' of specifying the
> characteristics the app required and having a search done by the browser to
> find services provided on available devices that match that schema.

And that would be bad because? You see where I'm going with this? I want the browser to do most of the work - specially dealing with all the UUID stuff. I don't ever want to see a UUID in my JS code - let alone ever have to write one. And I certainly don't ever want to have to debug stuff that contains UUIDs - that would be a nightmare: imagine you would have to find these Bluetooth spec tables and do manual lookups for what those darn things mean. It would be super painful. I want to just see: "heart_rate_monitor" or whatever. 

If the browser than maps "heart_rate_monitor" to something under the hood, then that's great. 

> But
> service UUIDs are designed to efficiently solve that.

If the strings are unique, as it the case with the enum, I don't see how using a UUID is more efficient? The are both unique strings. 

What am I missing?

Received on Friday, 8 August 2014 19:20:02 UTC