Re: [boost] Logging library review.

From: Scott Woods (scott.suzuki_at_[hidden])
Date: 2008-02-19 04:20:49

----- Original Message ----- 
From: "Jurko Gospodnetiæ" <jurko.gospodnetic_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, February 19, 2008 12:13 PM
Subject: Re: [boost] Logging library review.

>   Hi Scott.
>
>>>   * Filtering based on logged data. E.g. imagine logging airplane
>>> takeoffs and landings and wanting to log only landings for airplanes
>>> coming in from Frankfurt.
>>>
>>>   * Filtering log messages so that they end up getting written to only
>>> some destinations. E.g. specifying at run-time that you want information
>>> about those same airplanes from Frankfurt logged to the output screen
>>> while all output, including this one, gets logged to the main network
>>> logging server.
>>
>> Could you elaborate a little here? Are you implying that the 
>> configurability
>> of the logging library does not extend to the behaviours described above?
>>
>> Or that some canned filters might be provided by the library to ease the
>> pain of implementing those behaviours?
>>
>> Or are you after something more explicit, i.e. the formalization of the
>> logging data say, into columns, and the ability to test presented 
>> messages
>> by reference to those columns?
>
>   You can implement the aforementioned functionality by wrapping the
> library's logging calls with your own that then take the input
> parameters, and decide whether to log based on them. Then that wrapper
> layer can select one of many prepared logger objects or update the
> logger's destinations and that way decide where to log the message.
>
>   I tried implementing this. It is doable, but just seemed complex.

Ahah.

Yes, got it now. You want routing of logging based on runtime
inspection? Feels like something that might be doable through
extension of the proposed library, i.e. construct filter objects that
know how to route and the possible loggers. This would end up
being something like what you did but even less pretty? :-)

Thanks,
Scott