-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Darryl Green
In what way isn't this a "well designed bolt on to IOSTREAMS"? I can see is that it is more general than is necessary if one takes the view that iostreams provide all the facilities/customisation points you could need. I'm not of that view. [Brian Braatz Writes:]
Hmm.. I can better explain what I am suggesting this way: There are a lot of smart people throwing a lot of good points of variations at the logging library. Logging is somewhat of an issue that is difficult to solve because you cannot make everyone happy (everyone seems to have varying needs) I see the logging concept as either a device or a sink in iostreams. One that has the right balance of concrete design and points where the user can supply functionality (policies) to allow for at least speaking to most of the issues. I see this device as something I can build using template programming to meet my needs. I also see the dynamic filtering in iostreams as something very useful for production usage of logging. I see how to output and split and or manipulate the log output as something that, again, rides on iostreams. Things for example I PERSONALLY need out of a log: 1- Might Need to be able to re-direct to the ACE logging service 2- Windows Event Log 3- A file on disk 4- I might need multiple files on disk- one that is HIGH LEVEL interesting information and another that is the details (previous work has shown me this works very well in a production environment) 5- I might need to send the log to different "devices' simultaneously -I.e. another program over a socket, and my normal logging file. Because this is an issue that has so many perspectives, my suggestion is to think along the following lines: 1- Put enough policies into the design so the user can get what they need out of the lib (everyone has very different needs is my assumption) 2- Think about making the logging lib a conceptual extension of iostreams in design