Hi all,
The core team discussed what needed to happen to stabilize the D-Bus API, with particular focus on various properties that communicate the state of the pool and its parts[1]. I took some brief notes (more ideas and issues, really):
* internal state & enums vs API-presented
* adding new enumerated states later vs initially not using using all states specified, or committing to not adding more states, or only "bad" states
* Not breaking older clients
* Specifying how old clients should treat values they don't know about
* How are clients expected to use states, anyway?
* generating signals vs making values available in properties. What about generating signals for things not also available via a property?
* Can we add/remove D-Bus interfaces (i.e. the current capabilities of the pool (e.g. an incomplete pool has some but not all the capabilities of a complete&running pool)) based on state, and does this implicitly communicate the state of the pool so we don't need a property?
* We'd want signals for interfaces added/removed (see https://github.com/stratis-storage/stratisd/issues/1377)
That's what I wrote down. Any thoughts?
Regards -- Andy
[1] For reference, see the DBus API Specification on the website: https://stratis-storage.github.io/DBusAPIReference.pdf