Reports as system-state Observers

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



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.




More information about the Mir-devel mailing list