Early review of std.logger

[Robert Schadek]

On 10/15/2013 04:06 AM, Eric Anderton wrote:
> 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.
IMO these libraries are to heavy. Especially with phobos inclusion in mind.
>
> Here's what I think is missing:
> - System log support (as others have mentioned).  This would be syslog
> or WEL, depending on environment.
This is sort of the idea of the design, I can't anticipate your needs
therefor I should not try. I should try to give you guidelines or a
framework to work against.
>
> - 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.
See previous point
>
> - 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.
>
Passing a thread id with a log message, ok! shared!?
> 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.
See previous point
>
> - 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.
at one point the logger had names, but I thought on how to get the
correct names to them. This lead to some config file and I don't want that.
>
> - 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.
there already is a global log level
>
> 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