| 2016-03-09 11:31:54 |
Alan Griffiths |
description |
We have three(!) ways to configure logging:
1. (On startup configuring the server) server.override_the_logger([&]() ...
2. (On startup configuring the client by a debug API) Override ConnectionConfiguration::the_logger()
3. (At any time) mir::logging::set_logger(config->the_logger());
The first method is a public API and directs the output of the server reports and of calls to mir::log* (at least until the third method is used).
The second method is a private API and directs the output of client reports. (But not calls to mir::log*.)
The third method is a public API and directs the output of calls to mir::log*. (But not the server reports nor the client reports.)
It wasn't confusing before the third method was introduced (with the mir::log* functions). Maybe we should deprecate it? |
We have three(!) ways to configure logging:
1. (On startup configuring the server) server.override_the_logger([&]() ...
2. (On startup configuring the client by a debug API) Override ConnectionConfiguration::the_logger()
3. (At any time) mir::logging::set_logger(config->the_logger());
All of these are C++ APIs and none are part of the client "toolkit".
The first method is a public API and directs the output of the server reports and of calls to mir::log* (at least until the third method is used).
The second method is a private API and directs the output of client reports. (But not calls to mir::log*.)
The third method is a public C++ API and directs the output of calls to mir::log* and the client reports (unless the second method was used). (But not the server reports.)
It wasn't confusing before the third method was introduced (with the mir::log* functions). Maybe we should deprecate it? |
|
