> Thanks. I think we should establish a tradition for reviews on this > forum. The Boost review model has functioned very well, in the sense > that it has consistently produced two outcomes: excellent libraries and > pulp-beaten library authors. So I'd opt if at all possible for a tough > review process that produces good libraries as opposed to a nicey-nicey > process that fosters a low barrier of entry.
Understood and accepted. > > As I guess you suspected already, I have a few critical comments about > the proposed libraries. In brief, the library as proposed: > > * does stuff that I don't care about (creation of logs, pluggable > writers, overridable logging functions); Examining each one individually: 1) creation of logs - Do you mean having to specify a log file? I'm not 100% sure what you mean by this. 2) pluggable writers - Again, this was designed to be flexible as there are different situations where different types of log writers are useful and I didn't want to force one on the user. I forgot to state this before, my ideally I was hoping for several to be created and be part of the logging library if it made it to Phobos. This way several common options could be provided by the standard library, but if for some reason the user wanted something else, they could have it. Part of the reason for doing this was to not have people coming up with 20 different logging libraries that behave differently and have different interfaces just because the provided one doesn't work just the way they want it to. I felt it was a big step to allow the user to change the writing process if needed to whatever suited their needs and to keep how the logger was instantiated and used in code simple. If you have a different vision, I'd like to hear about it. Perhaps to make things a bit simpler, but still retain the power, we could have a default writer that will be used if no writer is specified. 3) overridable logging functions - If you don't mean the writer, then I didn't mean to do that. > > * does not do the two fundamental things that all loggers should do. > > Those only two things are: > > 1. Configure logging level during compilation > > 2. Configure logging level during runtime Actually, yes, it does do this. If you change the log level in the config file, it will be picked up by the logging library and the level changed accordingly during execution. I have a background thread that checks the file very 10 seconds. This way if you're running a server, you can change the level as needed for debugging without stopping the server. > > If you want to have your library accepted in Phobos, I suggest you take > a very close look at glog's interface and implementation. It's a simple > and robust library used by two major companies that depend on good > logging. To exaggerate a bit, "so"s seat-of-the pants sample code is > closer to the ideal logging library than your current draft. But I am > encouraged by the fact that you went through the aggravation to write > the code and show it to everybody, so hopefully you'll have the > willpower to push this through. I will take a look at it and document the potential design first before rewriting my code. Casey
