- From: Emill via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Feb 2017 18:16:35 +0000
- To: public-web-bluetooth-log@w3.org
Ok I see. It seems harder than I thought to get the ordering right when you have both promises and events. I think adding the field "read response or notification" to the event would be OK to solve the problem. But I however still don't really get the logic why the characteristicvaluechanged is fired when a read response is returned and see no really good use case for it either ;) Even if https://googlechrome.github.io/samples/web-bluetooth/read-characteristic-value-changed.html shows some use of it for polling battery status and similar - that must really be the only use case. But if one really wants to do the same thing when a notification and a read response arrives, one can just setup a function which is called both when a promise resolves as when the event is triggered. Most times you want to handle the read value in some completion handler for the read request and not handle the general event. So it is strange that the result is delivered in two different ways. Just because the read operation completes doesn't mean the value has been changed, so the name is not so good either if it's used for read responses. Android has different onCharacteristicRead and onCharacteristicChanged callbacks and nobody complains about that. Windows also delivers read results as a return value to the blocking (or async) read request function and notifications to a dedicated event handler (without read responses), which is exactly how a user would expect it to work and maps very well to the original GATT standard. I have actually seen no other bluetooth stacks that work in the way the current spec is defined, except CoreBluetooth that merges them into same. Actually our Flic protocol treats read responses and notifications in completely different way and is supposed to be dispatched to different parsers, but since we ignore invalid data it still works with web bluetooth. But I've seen other proprietary protocols as well where reading a value means something completely different than when a notification/indication arrives on the same characteristic. You also have the use case where someone wants to implement yet another gatt wrapper layer on top of web bluetooth - then that platform might define the api differently so you need to know if the value is the result of a read response or a notification/indication. You should note that even though at first glance one might think everyone uses GATT "as it is supposed to be", i.e. a server with an attribute db a client can read and write to, most larger consumer BLE products you can buy in stores I've seen always use custom characteristics with some binary protocol. The "glucose service", "cycling speed" etc were just something Bluetooth SIG came up with and hoped that they would be used :) but everyone has their own custom profiles just because almost everyone needs custom functionality. Just look at Fitbit's https://pewpewthespells.com/blog/fitbit_re.html, https://devzone.nordicsemi.com/documentation/nrf51/4.4.1/html/group__dfu__ble__service__spec.html or Apple's Apple Watch's protocol. Of course the "heart rate" services and similar are very good for testing out BLE functionality and for example when showcasing Web Bluetooth, but real products are more advanced than that. I think the web bluetooth standard is great in almost every point and has by far the easiest-to-use API I've ever seen of bluetooth stacks, but this little simple detail just keeps bothering me... -- GitHub Notification of comment by Emill Please view or discuss this issue at https://github.com/WebBluetoothCG/web-bluetooth/issues/274#issuecomment-277321185 using your GitHub account
Received on Friday, 3 February 2017 18:16:45 UTC