Re: [web-bluetooth] Don't fire characteristicvaluechanged for Read Responses

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 

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
 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,
 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
 using your GitHub account

Received on Friday, 3 February 2017 18:16:45 UTC