Reports as system-state Observers

Christopher James Halse Rogers chris at cooperteam.net
Fri Sep 16 07:16:24 UTC 2016



On Fri, Sep 16, 2016 at 5:08 PM, Christopher James Halse Rogers 
<chris at cooperteam.net> wrote:
> 
> 
> On Fri, Sep 16, 2016 at 4:51 PM, Alan Griffiths 
> <alan.griffiths at canonical.com> wrote:
>> On 16/09/16 02:51, Christopher James Halse Rogers wrote:
>>> 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.
>> 
>> 1. the user of the "Report" interface is the core code - which is 
>> simply reporting something. The code reads "report->xxx()" which is 
>> clear.
>> 2. we've had this name for years, without considering it a problem.
>> 
>> 3. Some implementations of "Report" log, some don't - which is the 
>> behaviour that was originally intended (and what we all want).
>> 
>> 4. I *think* the current issue is simply that we want to add support 
>> for multiple reports/observers so that code using Mir can get 
>> notifications without disabling the supplied logging/lttng options. 
>> We have existing generic "observer" code that can be used to 
>> composite reports.
>> 
>> In short, I agree that "Reports" are taking the "Observer" role from 
>> the pattern language, but I think the more specific name is good 
>> here and I don't follow why folks want the pain of a rename.
> 
> So, I think what's happening here is:
> 
> For some subset (including me) of the Mir team, the term “Report” 
> has a bunch of implicit semantics, including
> *) This is optional, for post-hoc human-based debugging only
> *) This is *purely* observational; it might log in any number of 
> ways, but the *only* state it's going to change is the state of some 
> logging system.
> *) The calls are approximately equal to printf; relatively cheap and 
> simple.
> 
> Which is why (1) and (2) are problematic - we *do* think that the 
> meaning of report->xxx() is clear, and isn't a problem, but we think 
> it means something significantly different to what you do.

Also - this is why the pain of a rename might be appropriate. At least 
some of our code that calls reports will *break* if it's used to drive 
code. Because we've not considered reports to be arbitrary callbacks, 
we do things like call them while holding locks that will cause 
deadlocks if code calls back into the object.




More information about the Mir-devel mailing list