It feels like a hack to me. In order to maintain the assumption that
switching reports should not affect the behavior of the system they
would need to be multiplexed, effectively additive. So you add a number
of active report implementations for any given report interface without
them canceling each other out.
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.
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.
On 15/09/16 09:43, r...@ubuntu.com wrote:
On a recent merge proposal¹, Alan wrote:
Huh. I *guess* you could use the logging interface for detecting display
configuration changes.
You have that backwards. The reason we have the report interfaces is
that there are things
that need reports from Mir that are not logging.
I remember long discussions when we introduced reports about why we
didn't just log directly.
This is an example of something that isn't logging or lttng.
I don't particularly mind using Reports as a method of system
implementation², but I think that the current social expectation around
Reports more closely matches “the various mir::report::* interfaces we
have are fundamentally debugging aids, and correct system operation
would not be impacted if we entirely removed them”.
As far as I'm aware, with the exception of ::new_configuration(), this
is currently the case.
If we *are* going to treat Reports as something that shells can
generically hook into to drive control flow we're going to need to be
more careful about the environment we call them in. For example,
currently if a shell hooks into new_configuration() and requests the
base_configuration() we'll deadlock. I've not worried about ensuring my
code doesn't hold any locks when calling into a Report, nor have I
checked that during reviews, because I've expected the Report
implementations to be roughly pure functions.
So, I'm happy for us to use Reports as a general introspection method,
but I suspect that many on the Mir team don't currently think they are,
and we'll need to change our behaviour if they are.
¹:
https://code.launchpad.net/~raof/mir/notify-shell-of-display-configuration/+merge/305189
²: Modulo the concern that, currently, this means that we don't
guarantee that debugging information is available, and a naive
implementation hooking into a report will destroy its use as a source of
post-hoc debugging information.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
