----- Original Message ----- From: "Jurko Gospodnetić" <jurko.gospodnetic@docte.hr> To: <boost@lists.boost.org> 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