{"action":"created","issue":{"url":"https://api.github.com/repos/WebBluetoothCG/web-bluetooth/issues/274","repository_url":"https://api.github.com/repos/WebBluetoothCG/web-bluetooth","labels_url":"https://api.github.com/repos/WebBluetoothCG/web-bluetooth/issues/274/labels{/name}","comments_url":"https://api.github.com/repos/WebBluetoothCG/web-bluetooth/issues/274/comments","events_url":"https://api.github.com/repos/WebBluetoothCG/web-bluetooth/issues/274/events","html_url":"https://github.com/WebBluetoothCG/web-bluetooth/issues/274","id":171433039,"number":274,"title":"Don't fire characteristicvaluechanged for Read Responses","user":{"login":"Emill","id":1660778,"avatar_url":"https://avatars.githubusercontent.com/u/1660778?v=3","gravatar_id":"","url":"https://api.github.com/users/Emill","html_url":"https://github.com/Emill","followers_url":"https://api.github.com/users/Emill/followers","following_url":"https://api.github.com/users/Emill/following{/other_user}","gists_url":"https://api.github.com/users/Emill/gists{/gist_id}","starred_url":"https://api.github.com/users/Emill/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Emill/subscriptions","organizations_url":"https://api.github.com/users/Emill/orgs","repos_url":"https://api.github.com/users/Emill/repos","events_url":"https://api.github.com/users/Emill/events{/privacy}","received_events_url":"https://api.github.com/users/Emill/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-08-16T14:45:00Z","updated_at":"2016-08-17T14:32:04Z","closed_at":null,"body":"Now characteristicvaluechanged is fired both for read responses and notifications. I don't think results of readValue should be sent to the characteristicvaluechanged event. It's better to just return the value in the promise. That makes it easier to write code that uses GATT reads, because you can then easier relate a read response to a particular read request.\r\n\r\nAlso, now as far as I can see, it's impossible to distinguish a characteristicvaluechanged that happened due to a read from one that happend due to a notification, which might be important when you want to implement something on top of GATT.\r\n\r\nThe term \"characteristic value changed\" also does not apply really to the read procedure; the value hasn't changed, you just got a copy of what's stored in the peripheral. For notifications however, the value has usually changed when a notification is sent."},"comment":{"url":"https://api.github.com/repos/WebBluetoothCG/web-bluetooth/issues/comments/240430620","html_url":"https://github.com/WebBluetoothCG/web-bluetooth/issues/274#issuecomment-240430620","issue_url":"https://api.github.com/repos/WebBluetoothCG/web-bluetooth/issues/274","id":240430620,"user":{"login":"Emill","id":1660778,"avatar_url":"https://avatars.githubusercontent.com/u/1660778?v=3","gravatar_id":"","url":"https://api.github.com/users/Emill","html_url":"https://github.com/Emill","followers_url":"https://api.github.com/users/Emill/followers","following_url":"https://api.github.com/users/Emill/following{/other_user}","gists_url":"https://api.github.com/users/Emill/gists{/gist_id}","starred_url":"https://api.github.com/users/Emill/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Emill/subscriptions","organizations_url":"https://api.github.com/users/Emill/orgs","repos_url":"https://api.github.com/users/Emill/repos","events_url":"https://api.github.com/users/Emill/events{/privacy}","received_events_url":"https://api.github.com/users/Emill/received_events","type":"User","site_admin":false},"created_at":"2016-08-17T14:32:04Z","updated_at":"2016-08-17T14:32:04Z","body":"Hi.\r\n\r\nIf 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.\r\n\r\nActual 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.\r\n\r\nHaving 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.\r\n\r\nSo, 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 :)"}}
{"actor":{"display_login":"Emill"}}