[bind10-dev] Fwd: Re: Topics for BIND 10 call tomorrow (2011-06-21)

[Stephen Morris]

A couple of other things about logging that we may want to consider in
our discussions:

1) A very trivial point (and I'm almost embarrassed to mention it) is
removing the comma between the message code and the text of the message
(e.g. "AUTH_CONFIG_CHANNEL_CREATED, configuration channel created").
Originally there to fit in with the rules of English, I now think that
it will be a hindrance, e.g. when parsing syslog output.

2) A further reflection on the message prefix.  All logging output
includes the name of the logger in the output (e.g. [b10-auth.datasrc]),
yet all message codes also include a module identification (the AUTH_ in
the example above).  As we seem to be following the convention that all
messages in a single module are logged by the same logger, are we
duplicating information?

On the other hand, the prefix does unambiguously indicate what module
raised the message.  If we publish a list of modules and their
associated prefixes, the descriptions would not need to include
information as to what component raised the message since that could be
inferred from the message code.

In addition, although we haven't done so yet, we may want loggers that
cross modules; for example if we want to trace a message through the
resolver, we may decide to log the trace messages - in whatever module
they are raised - using a special logger.  (That way we can control
trace output with a single configuration.)  If we do that, the prefix
can be used to quickly identify the origin of the message.

Stephen


-------- Original Message --------
Subject: Re: [bind10-dev] Topics for BIND 10 call tomorrow (2011-06-21)
Date: Mon, 20 Jun 2011 10:49:00 +0100
From: Stephen Morris <stephen at isc.org>
To: bind10-dev at lists.isc.org

A bit detailed, but a couple of cosmetic issues that may be worth
addressing the next release (which formally includes logging):

1) Message names: all our messages have a unique identification that
will allow us to determine what the message is, even if the text has
been translated into another language.

We have two styles of message names: words joined by underscores (e.g.
DATASRC_CACHE_REMOVE) and word abbreviations concatenated together (e.g.
RESOLVER_QUSETUP).  Ideally we should decide which style we want to use
and adopt it consistently.

2) Message files allow a $PREFIX directive to provide a string that is
prepended to all messages names in the file.  The original idea was that
it provided a prefix added to the message symbols in a program, but that
the messages logged would omit the prefix.  However, some time ago we
decided to include the prefix the latter.

For this reason, I think that $PREFIX has now outlived its usefulness:
it should be removed and the prefix incorporated into the message name.
 A second reason for getting rid of it it to help users that want to
create local-language versions of the messages.  A starting point for
that would be a listing of all messages capable of being produced by the
system.  A simple "find" command can list all messages, but as the
message names do not include the prefix, the process of producing a
replacement file is more complicated than it need be.


Stephen