Using glog's design for Phobos?

[Joe Greer]

Walter Bright <newshound2 at digitalmars.com> wrote in
news:i574ns$11t2$1 at digitalmars.com: 

> 
> Ok, I'm going to get flamed for this, but,
> 
>      I don't get it
> 
> I do logging all the time. It's usually customized to the particular
> problem I'm trying to solve, so it involves uncommenting the right
> printf's and then running it. Voila. Done.
> 
> The logging libraries I've seen usually required more time spent
> installing the package, getting it to compile, reading the
> documentation, finding out it doesn't work, rereading the
> documentation, etc., etc., than just putting in a #@$%^ printf, and
> Bang, it works, cut & print. 
> 
> Even worse, the logging libraries are loaded with a grab bag of
> trivial features to try and puff it up into looking impressive. They
> always seemed to me to be a solution in search of a problem.
> 
> Shields up! what am I missing about this?

In general, I would tend to agree that some logging libraries are pretty 
complicated and hard to just dive in and build what you need without 
spending a week learning the library.  However, in commercial 
applications, espcially servers, there is often the need for standardized 
logging messages that are really part of the server's output and not just 
something for one off debugging.  Think in terms of inetd, smtpd, or some 
commercial server.  These need to continually log messages containing one 
or more of timestamp, location of where message originated, severity of 
message (note, error, warning, etc), thread id, and other things I am not 
thinking of at the moment. :)  Furthermore, the output may get targeted 
to multiple streams such as console, debug out on windows, files, one of 
the system event logs.  Furthermore, files may roll like the unix system 
log based on some criteria (size, date).  Etc.  There are a lot of things 
to consider.  A good approachable library can make assembling the right 
combination of logs pretty simple.  Many people consider it important to 
be able to turn the logging off and leave minimal overhead (I personally 
find that applications that need logging, really just want to leave it 
on, even if the programmer's don't think they do.  Bugs are often time 
consuming to reproduce and your customer may not be thrilled with the 
prospect of helping you find your bug.)  There are probably other things 
I am forgetting, but hopefully you get the idea.

So, anyway, I can see the need for a logging construction kit of some 
sort.  Ideally though, it would make things easy to construct a log that 
does what you need without spending a week learning the library.  :)

joe