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