RFC: Encapsulate PeripheralProperties
rib opened this issue · comments
Considering #189 I was thinking it could make sense to track services for peripherals using a HashSet instead of a vector to make union operations much simpler as new service advertisements come in but one issue with that is that PeripheralProperties is public API.
Conceptually though I'm not sure that it's ideal to have an open struct for all advertisement state where there's not really a clear bound on the scope of what could be piled into this struct in the future.
As-is querying a peripheral's properties() also means copying all this state each time which maybe isn't always needed.
I'm wondering whether it would be fine to just encapsulate this state behind individual Peripheral getters instead of grouping the state together.
I can't really think of a reason why applications would need an atomic snapshot of these properties in aggregate? (the state itself isn't captured atomically by the backend so it's not preserving some kind of temporal data consistency from the device)
The address is already accessible via api::Peripheral::address, so that's covered and everything else looks like it would also be reasonable to expose via the Peripheral api.
Does this sound reasonable? It would be a notable API break though. That said though it would probably be easy enough to maintain the existing properties() api returning an aggregated PeripheralProperties and a simple shim over any new getters which could possibly be marked as deprecated.
In relation to this, I was wondering what is a use case for the discovery_count in PeripheralProperties? It kind of seems like an internal debug number on the face of it?
I experimented with this while looking at addressing #189 and could potentially take a stab at updating the other backends along the same lines if this seems like a good direction?