Are FetchProperties values better suited as D-Bus properties than return values in a method?

[jbaublitz]

During discussions around stratisd cockpit integration, the question has come up around whether the values returned over the FetchProperties interface are better suited as strict D-Bus properties here. There seems to be a way to preserve our format of application-level error reporting that does not break GetManagedObjects if stratisd fails to retrieve a property. It would simply return the failure status and an error message without causing the whole call to fail. Currently, @mulkieran and I agree that these volatile properties that can fail are better suited to their own interface regardless of whether they stay return values or change to properties. However, our concern around leaving them as return values is primarily because of the work on #2146. It appears that if we leave them as return values, we will force consumers of the API to receive a signal to get some of the properties, and then after, call into the FetchProperties interface to get the rest of the values. This seems like it could cause problems for consumers and might go against the expectation for InterfacesAdded signal contents as outlined in the D-Bus specification. @mulkieran has brought up some very reasonable concerns around the fact that these values will be constantly changing while actively writing to a Stratis filesystem and so it may not be helpful if we're constantly sending notifications about the property changing when this is happening so rapidly and often for potentially longer periods of time.

The main considerations can be summarized as follows:

• Would making these values D-Bus properties work better for the emitted signal on object creation?
• Would we cause performance problems constantly sending out signals for rapidly changing numerical properties?
• If we add a large number of properties to our FetchProperties interface, would we cause performance problems on GetManagedObjects calls?

[mulkieran]

We committed to this, closing in favor of #2817