Reports as system-state Observers

[Daniel van Vugt]

So actually... I now think it's OK providing the base class is named 
*Observer. And only some implementations would be called *Report.


On 15/09/16 10:10, Daniel van Vugt wrote:
> That's a good point. We don't need to change all the reporting locations.
>
> I still don't like the idea of having to delegate within reports, as
> well as changing their construction methods.
>
> Although I now realize my other concern that we'd have to change all
> reports at once for consistency also isn't true. If a user said:
>
>   --something-report=log,lttng,...
>
> and the SomethingReport didn't support multiple implementations yet then
> that's just a syntax error.
>
> I guess my remaining concern that's unresolved is the existing
> assumption that reports don't affect the control flow of the server. But
> that's really just a naming issue -- if it was called SomethingObserver
> then it would be OK. Just the word "report" makes me think it is
> ineffectual to server behavior.
>
>
> On 15/09/16 10:01, Christopher James Halse Rogers wrote:
>> On Thu, Sep 15, 2016 at 11:57 AM, Daniel van Vugt
>> <daniel.van.vugt at canonical.com> wrote:
>>> 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.
>>
>> I agree, but
>>>
>>>
>>> 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.
>>
>> ...this wouldn't actually be true? We'd just make the_report_interface()
>> not an override point and instead always have the same implementation
>> (which would then delegate to whichever report implementations have been
>> registered).
>>
>>
>