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
