Reports as system-state Observers

[Daniel van Vugt]

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).
>
>