Early review of std.logger

[Eric Anderton]

On Tuesday, 15 October 2013 at 15:16:44 UTC, Andrei Alexandrescu 
wrote:
> Eric, could you please enumerate a short list of features of 
> log4j that you think would be really missed if absent?

Certainly.  Here's my top 3, with some background to explain why 
I think they'd be missed.

- Hierarchical logging with a centralized (singleton) logging 
facility.  The strength of this is that it would allow us to 
freely integrate D libraries that use std.logger, yet filter 
their log output from *outside* the library through the 
std.logger API. This can be accomplished by tagging each log 
event with a category name.  Log events are then filtered by 
prefix matching of the category name, as well as by log level.  
Without this feature, library authors would have to provide 
explicit API calls to manipulate their library's logging, or 
require API users to pass logging contexts forward to the library.

- Configurable output strategies for each log category.  In 
log4cpp, these are known as "appenders."  Appenders need not be 
registered explicitly for each category, but can be registered by 
category name prefix match, just like the filtering for the 
hierarchical system (above). The idea is to allow for different 
formatting strategies and output targets, including the logrotate 
issue I mentioned earlier.  This provides a nice integration 
point to tackle basic capabilities today, like file logging and 
syslog support, and more advanced features by 3rd party authors.

- Nested Diagnostic Context support ("Mapped Diagnostic Context" 
in log4j).  The NDC facility in log4cpp/log4cxx is incredibly 
handy for cutting down on the amount of data one usually puts 
into a given log event.  The gist of an NDC is just a way to 
bracket a series of log calls with a prefix that is emitted with 
the rest of the log line.  These contexts are maintained on a 
thread-specific stack, such that each log event is prefixed with 
all the information in the entire stack, at the time of the 
event. Without this, one winds up re-inventing the concept 
(usually poorly) to forward the same information to each call to 
emit a log message.  It also eliminates the need for a stack 
trace in a log message in most cases, which is something that 
people who use SIEM software (e.g. Splunk) would appreciate.

There are other things that would be nice - configuration file 
support, lazy evaluation of log event arguments, custom output 
formats - but I think the above is really core of what's needed.

For what it's worth: my opinions mostly come from my experience 
in integrating with log4j and log4cpp.  Log4j is a very 
heavyweight library - I don't think we need anything anywhere 
close to that nuanced.  In contrast, log4cpp is very small 
library and worth a look as something that may be a good model 
for what std.logger could accomplish.

- Eric