Hi Neels,
On Wed, Jul 25, 2018 at 04:22:09PM +0200, Neels Hofmeyr wrote:
A) The hardcoded logging landscape on program startup
without config.
(Maybe this isn't all that important, including it nevertheless.)
1) a command to reset all to hardcoded defaults?
ACK
B) A "normal" logging behavior configured
by the user. We need:
1) a command to set all categories at once
to set all to one level, or to set all to one set of (configurable) defaults,
like a template?
2) a command to tweak individual categories
ACK.
C) Temporarily reducing the logging on all
categories: silence the log.
Even though a category is "normally" set to INFO, after this command it
can
be forced down to only log e.g. NOTICE. But if a category is already on
ERROR, leave it down there and do not lift it up to NOTICE.
1) a command to temporarily reduce all categories.
2) a command to temporarily reduce individual categories.
Not sure for what one would use that. You could switch off logging completely
and re-enable it later?
D) Temporarily increasing the logging on all
categories: show everything.
Even though a category is "normally" set to ERROR, after this command it
can be forced up to e.g. INFO. But if a category is already up at DEBUG,
don't reduce it to NOTICE.
1) a command to temporarily increase all categories.
2) a command to temporarily increase individual categories.
3) we need to decide whether temporarily increasing is stronger/weaker than
temporarily reducing. Depending on the implementation, it could also be
"last one wins" (which IMHO would be best).
Sounds incredibly complicated to me.
T) Maybe we also want to unconditionally set
temporary levels, whether they
increase or reduce.
?!?
E) Remove temporary logging to go back to the
"normal" logging landscape.
1) a command to put everything back to "normal",
2) a command to put individual categories back to "normal",
3) a separate command to only remove temporary reduction, i.e lift the
temporary changes only if they cause less logging than normal,
4) a separate command to only remove temporary verbosity, i.e. only lift the
temporary changes if they cause more logging than normal.
WTF? Why all that complexity?
Honestly, I'm stopping at that point. Just finishing to read that one e-mail,
let alone the entire thread will cost me hours.
To me, it boils down to a hypthetical luxury problem, unless there's
somebody who is actually funding/contributing the amount of time
required to designing, debating, implementing, reviewing and merging and
overhaul of the logging sub-system.
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)