Re: [boost] Re: logging lib, v1.3

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2004-11-02 00:45:46

On Tue, 2 Nov 2004 02:51:27 +0000 (UTC), Darryl Green
<darryl.green_at_[hidden]> wrote:
> Caleb Epstein <caleb.epstein <at> gmail.com> writes:
> 
> > Take for example the ACE_Log_Msg structure from the ACE library (just
> > the important bits):
> >
> > class ACE_Log_Msg { [...]

> I'm not clear on your point here - do you/have you used the ACE logging
> facilities? What feature do you actually want, if any, from there?

I'm not requesting any particular features, just trying to help
explain what is my take on Johan Nilsson's earlier message.  John
apparently had a couple of questions about what Johan had written, and
I thought I'd try to help clarify.  Perhaps I'm muddying the waters.

It *can* be useful to package up some information along with a message
when logging it, and ACE_Log_Msg is just one implementation of that. 
I'm neither fer it nor agin it.  Though I will exercise a modicum more
conviction at the polls tomorrow...

 > I certainly don't want a logging lib that collects "interesting stuff" on
> the off-chance that some output formatter might use it (and there have already
> been complaints about coupling - something like this is going to make it worse).

Fair enough.  It should be do-able to add this sort of thing in a
special appender, if needed.  Or see below.

> If what you want is something like the ability to have a modifier add this sort
> of information to the message, it already exists. The only question is, in what
> form is the message and the data added by the modifier? There is nothing
> stopping you from (for example) putting XML into the message, and having the
> modifiers add additional elements, then having an xml processing appender
> pick/chose and format these elements. Now, that sounds like overkill, but in
> some systems that may be a great idea, because the appender is actually just
> chucking this data in a file, or across a network, and some log
> view/query/filter tool can process the XML any way it likes. A lighter-weight
> version might just put attrib=value entries into the message, with newlines
> separating them or... If that isn't enough, as I've said before, it is possible
> to have some completely custom "string" and "stream" if that works for you.

Very interesting.  Maybe users who want a structured-type log message
(which collects this extra info), could implement one as their
"string" class.

> Maybe what is really missing is a clear set set of requirements the libary
> needs to address. FWIW I think the following is a reasonable set, without
> ending up with an everything including the kitchen sink result:
> 
> The library must provide a logging framework with a fairly minimal, portable
> set of facilities with few dependencies. 
> The logging library must be very efficient in handling disabled "logs".
> 
> The logging library must be user extensible to add new output (appender)
> facilities. This should be very easy and not require in-depth knowledge/study
> of library/its docs to do. Appenders, which are likely to have system
> dependencies, should not be tightly coupled with the core logging facilities.

Nicely put.

> The logging library must be user extensible to add new modifier facilities.
> This should be very easy and not require in-depth knowledge/study of
> library/its docs to do. Modifiers, which are likely to have system
> dependencies, should not be tightly coupled with the core logging facilities.
> 
> The library must scale well. This should include the ability to (efficiently)
> use a very minimal form of the library in small, perhaps single-threaded only,
> apps as well as achieving good performance on multiprocessor platforms in
> multithreaded apps.
> 
> The above points cover basic, portable usage. However, there are many
> environments where more customisation is needed, possibly non-portably. Making
> some components of the library generic can address this, but beyond some
> (possibly useful in their own right) example/test cases, I don't think actual
> implementations of a wide variety of these options need be included in the
> library, though over time it could be extended with additional submissions.
> 
> Customisable Configuration/control of log enabled/disable, which appenders
> particular logs write to etc. One general purpose way of doing this at least
> must be provided.
> 
> Customisation of the form in which log information is provided to the log.
> As per earlier requirements, a stream interface at least must be provided.
> Another interface, perhaps one allowing some form of arbitrrary attribute/value
> entry might be provided at least as an example.
> 
> Customisation of the form in which log messages are transported to
> modifiers/appenders. Currently the lib uses std::string for this. Perhaps a more
> highly tuned type could be provided by default - one where modifiers
> directly/efficiently prepend (as well as append) through a stream interface
> would be useful. Appenders really only need to receive a character iterator
> range. However, more wildly different types should be possible and at least an
> example provided (eg. some form of sequence of attribute/value pairs - maybe a
> map<std::string,boost::any> would be a good example?).

I think this is where a structured log message-as-string object might
come into play.  It would just need an ostream& operator<<() and voila
you have your custom log information

> I actually think the current proposal goes a long way towards meeting all of
> these (there are some areas that need "fixing" but I think the basic design is
> there). Are there any other design issues that need to be resolved or is it only
> a case of the implementation having a few gaps/bugs?

I agree.  John's submission is very nice as-is.

-- 
Caleb Epstein
caleb.epstein_at_[hidden]