- From: Emill via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Aug 2016 14:32:05 +0000
- To: public-web-bluetooth-log@w3.org
Hi. 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 (https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v8.x.x/doc/8.1.0/s110/html/a00105.html), serial port emulating services (http://support.dialog-semiconductor.com/resource/da14580-dialog-serial-port-service-source-code), 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 https://github.com/WebBluetoothCG/web-bluetooth/issues/274#issuecomment-240430620 using your GitHub account
Received on Wednesday, 17 August 2016 14:32:14 UTC