Hi Chris, On Fri, Oct 13, 2017 at 7:18 PM, Christopher Collins <[email protected]> wrote:
> Hello all, > <snip> > *** Proposal > > I propose that we remove the `BLE_GAP_EVENT_CONN_CANCEL` event. Instead > of using this event type, the host would report a successful > cancellation via a `BLE_GAP_EVENT_CONNECT` event with an appropriate > status code. > > My rationale for this proposal is as follows. If you think of the BLE > stack as a state machine, a successful cancellation involves the same > state transition as a failed connect attempt. In both cases, the stack > transitions from "connecting" to "idle". For this reason, I think it is > easier for the application to handle both cases with the same code. I > imagine the application doesn't care whether a connect attempt failed > due to timeout or because it was cancelled. In both cases, the upshot > is that the connection wasn't established, and the application is now > free to initiate another connection. I believe the cause of failure is > mainly used in reporting the event, and the status code should give all > the necessary information for this. > +1 for this > *** Details > > * For cancelled connection attempts, I suggest the > `BLE_GAP_EVENT_CONNECT` event specify a status code of ` > > BLE_HS_EAPP` > (application error). This is not a perfect fit, but I am leery of > adding more error codes, as that imposes a burden on unrelated > application code. > What about BLE_HS_ENOTCONN? > * Because this is an API change, it would be best to introduce it > slowly. The `BLE_GAP_CONN_CANCEL` event would be marked deprecated in > the next release, and then removed entirely in the one after that. > > * The numeric identifiers associated with the event types would not > change. Instead, 2 (`BLE_GAP_CONN_CANCEL`) would be labelled > "reserved". > If we only want to keep API stable then making symbol value is not necessary since symbols are part of API, not their numerical values. However I can imagine that we can keep this as "stable ABI" so I don't mind keeping it as you described. > All comments welcome. > > Thanks, > Chris > BR, Andrzej
