adabru / BleWinrtDll

BLE for Unity 3d in Windows without UWP.
Do What The F*ck You Want To Public License
168 stars 52 forks source link

Chromium Bluetooth implimentation #17

Open nathanrona opened 3 years ago

nathanrona commented 3 years ago

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

adabru commented 3 years ago

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"?

nathanrona commented 3 years ago

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

nathanrona commented 3 years ago

this is a nicer source browser https://source.chromium.org/chromium/chromium/src/+/main:device/bluetooth/;l=1?q=bluetooth&ss=chromium%2Fchromium%2Fsrc

nathanrona commented 3 years ago

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

adabru commented 3 years ago

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.