Reports as system-state Observers

[Christopher James Halse Rogers]

On Thu, Sep 15, 2016 at 12:11 PM, Daniel van Vugt 
<daniel.van.vugt at canonical.com> wrote:
> So actually... I now think it's OK providing the base class is named 
> *Observer. And only some implementations would be called *Report.

I would also be happy with this; various components take an Observer 
(which provides a register-interested-party API), and Reports register 
themselves as interested parties.

> 
> 
> 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).
>>> 
>>> 
>> 
> 
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/mir-devel