Thanks for the coments, Andrzej. On Mon, Oct 16, 2017 at 11:54:31AM +0200, Andrzej Kaczmarek wrote: > 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?
That is another possibility. I was thinking BLE_HS_EAPP is mildly appropriate because it is the application that cancelled the connect request. It probably isn't that critical what gets used here, as long as it is unambiguous and documented. I have a slight preference for BLE_HS_EAPP, as BLE_HS_ENOTCONN seems to indicate a more generic "not connected" status elsewhere in the stack. > > * 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. That is true. I don't think there are any ABI concerns here. I wanted to keep the event codes unchanged in case any applications include them in log messages. That said, I would be surprised if anyone actually logs these values. Thanks, Chris
