Reports as system-state Observers

[Daniel van Vugt]

It feels like a hack to me. In order to maintain the assumption that 
switching reports should not affect the behavior of the system they 
would need to be multiplexed, effectively additive. So you add a number 
of active report implementations for any given report interface without 
them canceling each other out.

Not impossible, but it feels too ugly. I would prefer to keep reports 
for debugging/logging only where they don't affect the behavior of the 
server. And programmers can assume this is true without knowing the 
implementation details of any given subsystem.

The implementation is potentially also ugly. At each point where a 
report happens you can't any more say:
    report_interface->report_something()
because that would only call one implementation. So we would need to 
change the architecture of all reports and for consistency change them 
all. It doesn't sound nice.


On 15/09/16 09:43, raof at ubuntu.com wrote:
> On a recent merge proposal¹, Alan wrote:
>
>>> Huh. I *guess* you could use the logging interface for detecting display
>>> configuration changes.
>>
>> You have that backwards. The reason we have the report interfaces is
> that there are things
>> that need reports from Mir that are not logging.
>>
>> I remember long discussions when we introduced reports about why we
> didn't just log directly.
>> This is an example of something that isn't logging or lttng.
>
> I don't particularly mind using Reports as a method of system
> implementation², but I think that the current social expectation around
> Reports more closely matches “the various mir::report::* interfaces we
> have are fundamentally debugging aids, and correct system operation
> would not be impacted if we entirely removed them”.
>
> As far as I'm aware, with the exception of ::new_configuration(), this
> is currently the case.
>
> If we *are* going to treat Reports as something that shells can
> generically hook into to drive control flow we're going to need to be
> more careful about the environment we call them in. For example,
> currently if a shell hooks into new_configuration() and requests the
> base_configuration() we'll deadlock. I've not worried about ensuring my
> code doesn't hold any locks when calling into a Report, nor have I
> checked that during reviews, because I've expected the Report
> implementations to be roughly pure functions.
>
> So, I'm happy for us to use Reports as a general introspection method,
> but I suspect that many on the Mir team don't currently think they are,
> and we'll need to change our behaviour if they are.
>
> ¹:
> https://code.launchpad.net/~raof/mir/notify-shell-of-display-configuration/+merge/305189
>
> ²: Modulo the concern that, currently, this means that we don't
> guarantee that debugging information is available, and a naive
> implementation hooking into a report will destroy its use as a source of
> post-hoc debugging information.
>
>