Migration document is great - I'd be lost without it. I'm just trying to be sure I understand the two changes for "GATT Server Authorizable Write Commands" and "GATT Server Write Authorization and Peer Data".
If I understand the first one correctly. In previous versions, Write Commands for authorized characteristics didn't trigger the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event but just directly sent the BLE_GATTS_EVT_WRITE event and were always written. This despite the fact the ble_gatts_evt_write_t in the RW authorize request had an op field which could be BLE_GATTS_OP_WRITE_CMD. I even had a case in a switch() to handle that, never realizing it wouldn't be called.
In the new alpha version, other authorized writes will continue to go via the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event as they always have, and write commands to authorized characteristics will still trigger the BLE_GATTS_EVT_WRITE, but with an extra flag set to say authorization is required in that one case.
Is this correct? Is there a reason the change wasn't to send them via the RW AUTHORIZE event like all other types of writes requiring authorization? I assume it's because the Write COMMAND doesn't send an authorization reply, so it doesn't naturally go through the same path as all the other types of auth which do. So, because of that and the next change not to automatically write data, you need the extra flag and the handler needs to persist the data if they authorize it.
Secondly - the Server Write Authorization And Peer Data change.
If I understand this correctly - it used to be enough to just return BLE_GATT_STATUS_SUCCESS back to the sd_ble_gatts_rw_authorize_reply() method, and the data would be updated for you. This is however no-longer the case and you are also now required to fill in the rest of the auth_params write fields, update, offset, len and p_data in order for the data to be actually be updated on success, or I suppose you can instead do your own sd_ble_gatts_value_set() but just returning SUCCESS and leaving the other fields blank is no-longer going to update your data. Correct?
I'm guessing here if that's correct it's to save memory in the softdevice which doesn't have to hold onto data until the authorization is confirmed.
Thanks again for the migration document - I just wanted to make sure I understood fully the changes here as they both seem quite important.
