On 2007-04-03, JD <jean.daniel.michaud@gmail.com> wrote:
Concerning req id 3: Michael, I don't really get this statement. I think it's really to the library user (programmer) to decide which log shall be present or not. He's in charge of filtering the logs following the compilation configuration (debug or release). I don't think the library shall manage this by itself. Or maybe I did not get your point at all!
I think the idea here is to eliminate certain kinds of information from object files/binaries. That is, if the user decides to eliminate the "top-secret debug log" from release builds, the generated binaries should give no indication that this log exists at all.
I can't disagree more with this. IMO, logging is not at all a way to give information to the program user. In my mind, a logging library is intended only for debugging, journaling, auditing and performance measuring. Not a way to display error message or waiting message to the user. In my mind, these are totally different things. Please someone, give his POV on this, I think this is a major disagreement.
You're probably going to find yourself in the minority here. In many instances, a log might be the only way communicate an error to the user; consider, say, a webserver or NFS lock daemon. More generally, I think that a generally useful logging system will be able to handle arbitrary logging and won't be concerned with domains or specific usage patterns. -- Austin Bingham Signal & Information Sciences Laboratory Applied Research Laboratories, University of Texas at Austin 10000 Burnet Rd., Austin, TX 78758 email: abingham@arlut.utexas.edu cell: (512) 799-2444 office: (512) 835-3832