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
