New issue
Advanced search Search tips

Issue 614534 link

Starred by 0 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Sep 5
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocking:
issue 580406



Sign in to add a comment

bluetooth: define consistent GetValue behavior after WriteRemoteCharacteristic

Project Member Reported by scheib@chromium.org, May 24 2016

Issue description

For Characteristics and Descriptors, the result of calling:
 WriteRemoteCharacteristic()
then, before that operation completes, calling:
 GetValue()
should be defined.

Either, GetValue should always provide the value that the Write attempted, or it should not be modified until the Write succeeds.
 

Comment 1 by ortuno@chromium.org, May 25 2016

I don't think WriteRemoteCharacteristic should affect GetValue in any way. I can't think of any use cases for saving the value we attempt to write. I actually think it's confusing to save it because there are characteristics that use a write action as a signal to perform another action and characteristics from which the value read is different from the value written.

Also I think our documentation is just incorrectly worded[1]:

// Sends a write request to a remote characteristic, to modify the
// characteristic's value with the new value |new_value|.

I think this might imply that GetValue returns the value that we attempted to write but the bluez documentation is very explicit that the only time Value changes is for read requests and notifications/indications[2]

[1] https://code.google.com/p/chromium/codesearch#chromium/src/device/bluetooth/bluetooth_remote_gatt_characteristic.h&l=95
[2] http://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/gatt-api.txt#n121

Comment 2 by scheib@chromium.org, Aug 29 2016

I agree with Comment #1, and think that we should:

a) Update the BluetoothRemoteGattCharacteristic::WriteRemoteCharacteristic doc as per comment #1's [1], 
 replace ", to modify the characteristic's value with the new value"
 with " with"
b) Rename the parameter 'new_value' to be just 'value'.
c) Remove TODOs and close this issue.
d) Update [Web Bluetooth] spec, which currently states that the cached value should be updated. I've filed an [issue] there to do so.


[Web Bluetooth] https://webbluetoothcg.github.io/web-bluetooth/#dom-bluetoothremotegattcharacteristic-writevalue
[issue] https://github.com/WebBluetoothCG/web-bluetooth/issues/277
Project Member

Comment 3 by sheriffbot@chromium.org, Aug 30 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 4 by scheib@chromium.org, Aug 30 2017

Status: Available (was: Untriaged)
Project Member

Comment 5 by sheriffbot@chromium.org, Aug 31

Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Fixed (was: Untriaged)
The GitHub issue referenced in comment #2 and the Chromium CL[1] it references have both been merged.

[1]: https://codereview.chromium.org/2287273002

Sign in to add a comment