Thanks Chris, That's exactly what i was thinking implementation-wise. I don't think #3 is necessarily hacky, it is ok to collapse the two write ops for most uses, but still provide an indication of whether a response is expected. That's how the Android API implements it (not that it is necessarily a paragon of API design :)
https://developer.android.com/reference/android/bluetooth/BluetoothGattServerCallback.html#onCharacteristicWriteRequest(android.bluetooth.BluetoothDevice,%20int,%20android.bluetooth.BluetoothGattCharacteristic,%20boolean,%20boolean,%20int,%20byte[]) I was thinking of adding a similar `needs_response` field to ble_gatt_access_ctxt. The need to distinguish is actual, but not particularly pressing. I am supporting both ops for some specific device needs, but my write can fail for an application-defined reason (not just a gatt failure). If the peer executed a write-no-response and the write failed for an application reason, I would like to record that failure and report it through other channels, since the client will not get it otherwise. (Presently, i am doing that always, regardless of whether the client also receives an ack, so this is more of an optimisation.) simon On Wed, May 24, 2017 at 4:06 PM, Christopher Collins <ch...@runtime.io> wrote: > Hi Simon, > > On Wed, May 24, 2017 at 10:38:06AM -0700, Simon Ratner wrote: > > Hi devs, > > > > For a characteristic that is both WRITE and WRITE_NO_RSP, is there a way > to > > distinguish which operation was received from within the gatt access > > callback? Nimble will automatically send the response if requested, but > app > > may have different behaviour based on whether it expects the central > device > > to receive the response. > > I'm afraid not. That information gets lost in the ATT server code. To > propagate this information to the application, I think we would need to > do (something like) the following: > > 1. Define a new ATT op code: BLE_ATT_ACCESS_OP_WRITE_NO_RSP > 2. Modify ble_att_svr_write() such that: > a. it takes an op code parameter. > b. it forwards the op code to the ATT access callback. > 3. Add a boolean field to the ble_gatt_access_ctxt struct: no_rsp [*]. > > Step 3 is a bit hacky, but it maintains backwards compatibility. > Without the backwards compatibility concern, it would probably be better > to add a new GATT op for write-no-response. > > So I think it is a fair amount of work. I do remember making the > decision to collapse both write operations into a single opcode, > thinking the application would never care about this distinction. It > sounds like I may have made the wrong choice! Is the need to > distinguish among these two operations an actual or theoretical > requirement? > > Chris >
