W3C home > Mailing lists > Public > public-web-bluetooth-log@w3.org > August 2016

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

From: Emill via GitHub <sysbot+gh@w3.org>
Date: Wed, 17 Aug 2016 14:32:05 +0000
To: public-web-bluetooth-log@w3.org
Message-ID: <issue_comment.created-240430620-1471444324-sysbot+gh@w3.org>

If you just read the Bluetooth Core 4.2 specification "4.8.1 Read 
Characteristic Value", it is a standalone procedure which contains a 
read request and a read response. It does not seem to make any sense 
to "merge" the response value into the notification procedure.

Actual use cases may be anything that is using GATT for more advanced 
things. One might think that people only use GATT for basic stuff like
 "hard rate monitor" and "battery status" but that is far from the 
only thing what people do. Actually I'd guess almost all products on 
the market have at least one GATT service that is being used in a way 
GATT was not designed for. There are many products that have developed
 protocols that run on top of GATT to fulfill their needs. Examples 
are firmware update services 
 serial port emulating services 
 cryptographic protocols (https://github.com/aanon4/HomeKit). A 
firmware update service is probably the most common one among 
"advanced" GATT services. For these often the GATT structure does not 
make much sense, but they are limited to using GATT since that is the 
only way to communicate with a BLE device. For these protocols all 
GATT operations does not really mean "read the current attribute 
value" or "store this value in this characteristic", but rather GATT 
is only used for transporting or streaming data, so also getting a 
cached value if the device is disconnected for example does not make 
any sense. I'm currently aware of at least one cryptographical 
protocol over BLE that uses reads and notifications on the same 
characteristic in a totally different way. Once a read request is sent
 out it expects a read response containing a value with a specific 
format (encrypted in a specific way). Notifications are also enabled 
on the same characteristic but they have a different encryption and if
 it doesn't pass the decryption, the link is dropped.

Having multiple characteristics as you say, while it sometimes makes 
more sense to have one, only as a workaround for some BLE APIs, would 
also increase complexity in firmware + lead to longer service 
discovery times.

So, because I think it is no strange at all to be able to distinguish 
read responses from notifications, I see no reasons not to do so. I 
see this as a great opportunity to fix the spec _before_ the final 
version has become standard :)

GitHub Notification of comment by Emill
Please view or discuss this issue at 
 using your GitHub account
Received on Wednesday, 17 August 2016 14:32:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 17 August 2016 14:32:15 UTC