Early review of std.logger

[Eric Anderton]

On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
> Lets unleash the forces of constructive destruction.

So, not to be too heavy-handed with criticism on this library, 
but I think this should come up to par with solutions like log4j, 
log4cpp, or log4cxx, with respect to features and capabilities.  
Libraries like these have enjoyed a lot of very serious use, and 
once you have something like that in your project, it's hard to 
not use most of what they have to offer.  There's really not a 
lot of fluff in those solutions.

Here's what I think is missing:
- System log support (as others have mentioned).  This would be 
syslog or WEL, depending on environment.

- Guarantees or options for working with log rotation 
(logrotate.d).  It's nice to either know that you must restart 
your daemon once logs are rotated, or can configure logging to 
re-open handles automatically or when it detects rotation has 
occurred.

- Guarantees about threading and thread safety, with concessions 
to help keep log event streams coherent from thread to thread.  
Log formatting in particular could enjoy the ability to emit a 
thread id, so logs can be analyzed without confusing which thread 
is responsible for which chain of events.

Here's what I think would make this an amazing library:
- Nested Diagnostic Context (NDC) support.  This isn't heavily 
used in all projects, but it does a fantastic job of cutting down 
on the tendency to put tons of redundant information into every 
call to log().  In practice, this helps tremendously for 
debugging, as engineers stop pulling punches as adding rich 
contextual data to log lines becomes painless.

- Log "category" support.  Just some way to add an axis for 
filtering, so you can configure logging to block all log messages 
from one library, or just errors from another, at the same time. 
Under log4j, this is simply the module where the log event 
originates from - other libs let you use an arbitrary string.

- Filtering log events on another axis.  Loggers can already be 
configured with a log level.  But it would be nice to be able to 
set a global log level to dial in how much information comes out 
of the system across all logger instances.

That said, I do appreciate the compactness of this library.  It 
provides some very straightforward logging support and covers all 
the basic and important use cases.  But after using more 
feature-rich solutions, I can't help but think of all the places 
that I would feel inclined to go with a stronger solution, or 
extend this to do more of the kinds of things I'm used to doing 
elsewhere.  I think D has a chance to make an implementation of 
something on   par with log4j or log4cxx, easy to do, without 
needing anywhere near as much code.

- Eric