RE: [boost] Re: Logging Library over Iostreams? (was Logging Library-- Formal Review Request)

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-05-05 14:21:24

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> 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