adabru
Chromium Bluetooth implimentation
You may be interested in looking at the Bluetooth code of Chromium, they have a pretty inclusive implementation of Blutooth in C++ https://chromium.googlesource.com/chromium/src/+/refs/heads/main/device/bluetooth
That's a nice hint! The page you linked seems to say there is no active maintainer? That would make it more difficult to ask questions. Maybe there is another cross-platform foss project where bluetooth is not so "experimental"?
If you look here https://chromium.googlesource.com/chromium/src/+log/refs/heads/main/device/bluetooth is seems that it is rather active. Also given that it is implemented in Chrome browser Web-blutooth api, why do you consider it Exprimental?
For questions, maybee IRC or Slack ?https://docs.google.com/presentation/d/1abnqM9j6zFodPHA38JG1061rG2iGj_GABxEDgZsdbJg/present?slide=id.i283
this is a nicer source browser https://source.chromium.org/chromium/chromium/src/+/main:device/bluetooth/;l=1?q=bluetooth&ss=chromium%2Fchromium%2Fsrc
Notice they use wrl, which is now superseded by C++/WinRT https://docs.microsoft.com/en-us/cpp/cppcx/wrl/windows-runtime-cpp-template-library-wrl?view=msvc-160
If you look here https://chromium.googlesource.com/chromium/src/+log/refs/heads/main/device/bluetooth is seems that it is rather active.
That's a good point.
Also given that it is implemented in Chrome browser Web-blutooth api, why do you consider it Exprimental?
Based on a paragraph on the site you linked:
Future Work The API and implementation have many known issues. The initial API was heavily influenced by BlueZ. Low Energy GATT APIs are not consistent across platforms. Some of the high level abstractions built into device/bluetooth are difficult for clients. Several TODOs exist in the C++ header files, e.g. BluetoothAdapter::Observer. Primarily, the API should be split into fundamental Bluetooth concepts and seperate, optional, high level utility classes. E.g. receiving advertising packets should be routed directly to clients allowing contents of the individual packet to be inspected. Caching of known devices should not exist in the fundamental API, but be offered as utility classes. See also the Refactoring meta issue.
And this table: https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API#browser_compatibility
On the other hand, there are projects like https://www.btframework.com (commercial) where bluetooth is more relevant than in a web browser.