Brian Braatz <brianb <at> rmtg.com> writes:

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

Yikes. I guess you can easily enough do this with an appender that actually contains ACE_DEBUG(severity, log_msg_string) statements, but then you have 2 systems trying to do the same job in the one app, concatenated together. If what you want is to make each BOOST_LOG(x) access actually map to the underlying ACE mechanisms to do similar things, I wish you luck. I suspect it can be done, at last once the generalisation I proposed is included, but I'm not sure the result would really be "the boost logging library".

2- Windows Event Log

Assuming you don't want to use resources to do message formatting/il8n support, all you need is an ID and string to pass through to the event log. You could do that with an appender easily enough. To do something more elaborate you would need to be using some sort of structured msg/string type. If you do take that sort of approach any other appenders need to be able to similarly process the message to produce meaningful output.

3- A file on disk

Appenders to do this (and assorted variations) exist.

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)

Easy to do - connect one appender to the high level log and another to the low level log, or to both if you want to have the details + high level merged there.

5- I might need to send the log to different "devices' simultaneously

No problem.

-I.e. another program over a socket, and my normal logging file.

Not a problem, assuming you have an appender for the device/channel/whatever.

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)

Yes, up to a point of course. Also I'm not convinced that logging is a well formalised concept, or can be made into one productively, so I'm not sure I'd be keen to try to break it down into a formal set of policies. Just making accessible each type that can be usefully customised is enough imho. Trying to ensure that these types are orthogonal policies that can be mixed and matched is a big ask, I'm happy enough with just lumping them all together into the "manager" type. The library should have a default manager that is officially supported, and at least an example of an alternative one, but I don't think it is reasonable to have it offer a wide variety of policies as part of the library - it should be useable out of the box, and customisable by sufficiently adventurous/demanding users (not to say that a sufficiently widely useful alternative manager couldn't be added later).

2- Think about making the logging lib a conceptual extension of iostreams in design

I still don't see what concepts from iostreams you want. I can't see anything that you have asked for missing from the current design. Have you actually tried it? Darryl.