Re: [boost] Boost Logging library - first draft

From: JD (jean.daniel.michaud_at_[hidden])
Date: 2007-04-02 14:11:20

> 
> Now to the point. I understand and agree that the logging library
> should be simple to use but I see no reason we should sacrifice the
> extensibility for it. To my mind a carefully designed library
> interface is the way to go, not the functionality and extensibility
> limitation. And unfortunately, I see little ways of extension of your
> implementation to get the functionality I got used to. I may be wrong
> and may have missed something.
>

[All that follows concern the library I proposed. For more general 
comments on an eventual Boost.Logging, please refere to the end of this 
post]

There is no way to extend my library as basically it offers all what I 
need and look for from a logging library! :) No kidding.

> 1. The whole design looks more like a stream dispatcher rather than a
> logging library which has to be more complex. I see no scope logging

Ok so if I understand, and correct me if I'm wrong, a scope logging 
facility would be some kind of macro added at the beginning of a 
function. This macro holds an object (RAII style) that would log the 
function name in its constructor (with eventually arguments) and log the 
exit of the function in its destructor. I'll add it.

> support, no custom log record attributes, no filter or wide logging
> support, and I see no obvious way to implement these on the user side
> to plug them into your lib. The way to completely wipe out logging
> from the user code during compile time would be good too, though it's
> not very difficult to implement it.

- Log record attributes (what is it? just to be sure of what we are 
talking about.)
- filter
- wide logging (I guess it means internationalization (let's say i18n))

> 2. The logger object is a singleton which, I think, would be
> inappropriate once I would have custom attributes. I think the logger
> should be separated from the core library, which indeed would be a
> singleton. This would not only make attributes possible, but form a
> "source" concept. A logger would be an implementation of this concept,
> though allowing other implementations of "sources" (like, a
> third-party application console interceptor, for example).

For me the logger is the core of the logging library.
So the source is the logger. It's the object who is responsible to 
collect logs generated by the user? Does he format them?

> 3. The "sink" (or "target") concept is simplified down to a stream,
> which is not a best choice. Remember that the log record is more than
> just a string. It consists of a number of parts (attributes) - record
> number, time, source code location, severity level, and (yet another
> attribute) message text. There may be other user- or library-defined
> attributes. And the "sink" should be able to define which attributes
> to log and how to format them. In fact, a "sink" may apply its own
> filters to wipe out the unneeded records from the output. This is not
> possible with a simple stream "sink".

Ok it's clearer now. An attribute is what I call the element of the log. 
  Well I'm using my element_list as a description of the format of my 
logs. In doing such thing as:

"[" >> boost::logging::level >> "] - " >> boost::logging::filename

I am defining the format "attributes" of my logs. Ideally, user can 
define any class deriving from log_element and implementing the toString 
function for output.

> 4. The library is header-only, which will raise some problems in a
> complex applications that consist of more than one module. The logger
> instance will be visible only in one module, other modules will have
> their own loggers, which obviously mean problems with their
> initialization (which streams to add as "sinks"?). I believe that
> logging library should be implemented as a shared lib.

So, let's talk concrete. If you have two lib:
my_library.lib
my_other_library.lib
main.cpp

Including the header in each library will lead to having two differents 
instance of a logger in my final executable?
The header-only solution seems so great to me. Include and forget...

> 5. I think there are too many macros in the interface. I'd rather have
> BOOST_LOG as an inevitable minimum, but no more than that.

I didn't want the user to manipulate objects and variables. But that is 
not boost philosophy, I can understand that.

> If you are interested, I could describe my view of architecture of
> such logging library (I'm working on the implementation on an early
> stage). Though, I think, many of us already have such view in our
> minds and maybe have it implemented.
> 

Please, if this library is mature enough, submit it!!

> And finally some implementation-regarded notes (though I understand
> this was just a draft, I couldn't hold myself, sorry :) ):
> 1. The logger is default-constructible from the user's code, but it
> seems that you intended to make it singleton.

I'm calling the default constructor in the get_instance.

> 2. logger::get_instance is not thread-safe - function-scope statics
> are used.
> 3. You should not define namespace bl = boost::logging; in the library
> code.
> 4. Element global operators should be in boost::logging namespace.
> They will be reachable via ADL.

Does not compile with msvc.

> 5. Each logging record involves std::stringstream (even not
> ostringstream) construction, formatted output copying, and
> destruction. I'm afraid, that would be a performance impact on the
> application.

Yes that's a pb.
std::strstream logger::m_str ?

> 6. I believe, some of the "Logging typedefs declarations" might have
> been hidden into the logger class and renamed. Some other names (like
> null_deleter) might have been hidden to an internal namespace.
> 

[general comments here]

Actually I have no hope the draft I propose will grow to something 
acceptable. It was a way for me to sparkle the debate and have something 
to talk about. I have no pretension to write such library, at least alone.
Thank you Andrey, you comments are _very much_ appreciated. But still...

> PS: I hope I didn't kill your encouragement with my reply. This is the
> last thing I'd wanted to do.
> 

... I think I took this problem too lightly. We shall not focus on 
implementation at first but more on the requirements. Austin Bingham, in 
an other post, was also saying that we should first write the minimal 
requirements of the Boost.Logging library on some wiki or whatever... On 
the other hand, from the profile I draw in my summary earlier, 
Konstantin mention log4cpp (http://log4cpp.sourceforge.net) as a 
potential candidate. And still, some people propose their homegrown 
libraries... Like everybody here, I have a limited amount of time. I was 
wondering if it would be possible to assemble a small team led by some 
boost authoritative guy (Gennadiy?) to pull this.

JD