I dont know enough about the host to comment on whether we should change this API now or after release.
I think adding an address structure is a good idea. A question about one of your open points. The spec has confused me a bit in this regard. Isnt it up to the application to decide whether it wants to use a public device address or a random static address? A device can contain both, so how does one decide which one to use? I thought that was up to the app but maybe apps dont really care about this and we can leave it up to the host? > On Jan 26, 2017, at 6:41 AM, Andrzej Kaczmarek > <andrzej.kaczma...@codecoup.pl> wrote: > > Hi, > > I think it would be nice to do one more API refactoring before 1.0 release > and simplify using BLE device address in API. > > The current state here is similar to what we had with UUIDs in ATT code, > i.e. addresses are passed as pair of address type and address value and > there is no common way to e.g. compare or copy them. What more, with > Privacy enabled things are even more complicated since application needs to > chose which address to use when advertising or scanning and can use > different addresses for the same peer device. > > So I propose few changes: > > 1. Application does not specify own_addr_type in APIs > This should be selected automatically by host. By this I mean that > application tells host somehow at startup which address to use (public or > random static) and host will set parameters accordingly depending on > whether Privacy is enabled (IRK is provided) or disabled (no IRK provided). > > 2. Application should always use peer identity address, if possible > Since host manages resolving list in controller already, address resolving > will be done automatically anyway. We can then assume that for any known > device, the address we use in API is identity address (assuming our IRK is > provided and thus Privacy is enabled) and honestly it does not need to know > so-called OTA address, because this is what host and controller take care > of. The only exception here would be for new devices for which application > will have random (RPA) address at first, but as soon as we are paired host > should notify application about identity address of such device - for this > new event shall be added. > > 3. And finally, of course, we need nice type and helpers to store and > handle device address in uniform way: > typedef struct { > uint8_t type; // 0 = public, 1 = random > uint8_t address[6]; > } ble_address_t; > > This is what I have in mind now. It may some time to fix all the internals, > but before release we would just need external APIs redefined. Then we can > work more on optimizing the internals. > > Open points: > - selecting own address type could be automatic, i.e. host reads public > address from controller, if not available tries to read static random from > storage, if not available generates new one and stores it > - the same for IRK, i.e. read from storage, if not available randomize new > one > This can be however added later and old APIs can be just marked as > deprecated. > > Comments? > > BR, > Andrzej