reillyeon
commented
2 years ago As discussed in #535 it appears that the Bluetooth SIG has stopped maintaining this mapping in an easily machine-readable format. We've added a snapshot of the last time this mapping was more easily available to https://github.com/WebBluetoothCG/registries however I think in generally we want to avoid encouraging developers to use these names in favor of the unambiguous UUIDs.
So for your purposes (just understanding what a UUID is) I think the new mapping table we've provided is useful but exposing this through the API itself would be counter to our goals and also not particularly useful since the permission model requires an application to declare upfront the service UUIDs it is requesting access to and so would not encounter a situation in which it needed to be able to construct a human-readable name for one it is unfamiliar with.
"3. Have you found a problem with the way this API is specified or have a feature request? File it here."
I think this would be helpful for others during debugging and development, especially when dealing with devices that don't have much documentation.
I think you should specify a function to retrieve a service name or GATT description from a UUID if it's a known UUID. I have no opinions on how best to specify it... I just found myself doing this while learning the protocol for my Aranet4. It could even just come along with any of the interfaces already specified (
BluetoothRemoteGATTService,BluetoothRemoteGATTCharacteristic, etc...).No need to be exhaustive either, covering even some of the UUIDs will really make someone else's day a bit easier.
I extracted my own file containing Javascript Maps of as many descriptions that I could compile from around the internet: https://gist.github.com/ariccio/2882a435c79da28ba6035a14c5c65f22
Browser developers should be able to implement this pretty easily. No runtime overhead needed, it can be a constexpr map of the dev's choice, or as chrome does already, a fancy schmantzy static local.
In a better world, the Bluetooth consortium might make this more easily retrievable via an API or something. There are a whole bunch more 16 bit UUIDs listed on the SIG site, but I reject the idea of using 16 bit UUIDs for anything on principle.
There are a number of similar things implemented one-off all around the internet, including the Linux kernel Bluetooth stack. I'm going to file similar issues with other BLE toolchains/platforms I've used lately, why has nobody thought of this?
Sidenote: the links in the chromium source that supposedly point to a list of characteristics, largely seem to be dead. Did SIG ever provide a nice list of 128 bit UUIDs?