On Sat, 2010-03-13 at 22:14 +0300, Andrey Semashev wrote:
On 03/12/2010 05:05 PM, Darryl Green wrote:
Anyway - I've looked at the docs for boost.log and read some review comments to see if we could replace this with the proposed boost.log. I've reached the following (possibly wrong) conclusions:
1) there isn't a direct mapping from this style of logging
Except the filtering based on the message text, I'd say your case is covered by Boost.Log rather well. Some things, like having a source per severity level, are not required with Boost.Log.
Agreed. I should not have separated this from item 2 below.
2) the obvious approach of making each element of the channel identifier an attribute would seem ok - but I'm concerned that the cost of evaluating the filters would be significant
The cost will be more significant than comparing a pointer against NULL, that's for sure.
That is my major concern. In a server app with detailed logging/tracing available and many sessions generating messages the ratio of "disabled" "channels" to enabled ones can be very large, making the performance of the former very significant. However, I can't see a way to directly incorporate this sort of performance with the other desirable features of your library. Attempting to represent this scheme as some sort of specialised attribute (value) and filter still incurs a level of overhead in the attribute lookup and filter expression processing that is undesirable. Extending your lib by make our existing channel based log type into a logger feature and implementing open_record such that it applies the quick channel based filter first and returns a null record if the channel/logger is disabled would seem to be the best approach. It would also be desirable to use the set of sinks for which the channel filter passed to short circuit the core filtering by adding the set of sinks "attached" to the channel as an attribute of the message. Does that sound workable?
4) it isn't immediately clear how to support dynamic configuration of "filtering" and sinks
Well, the library allows to add/remove sinks, filters and formatters during the run time. You can simply call the interface methods as you would do it on the library configuration stage.
Ok.
5) attributes seem a little overloaded - the attribute as something to be filtered on and the attribute as something to be included in (formatted in to) the logged message roles are potentially different. It would be nice to have expensive to evaluate attributes that played no role in filtering but that were (after filtering "passed" the message) evaluated conditionally based on filtering.
It looks to me that it's already implemented, but not exposed to the user (since it's only an optimization). If an attribute is not used during filtering, and the filter rejects the record, the attribute is not evaluated at all.
Good.
6) There are use cases that boost.log can support (ones where the filtering is based on more "dynamic" attributes) that are not practical to support in the pure channel based model afaiks. I'd class most of these as "alarms" where there is some sort of thresholding or similar criteria applied to an attribute value (or combinations) to determine whether to log the message.
Hmm, not sure I understand what you mean here. Severity levels, perhaps? But you do use them, although they are a part of the channel name in your case.
I mean that your library makes it possible to write a filter that logs only if eg. packet_length is over 4K (assuming packet_length is an attribute) which is not possible using the early/cached evaluation implicit in the pure channel based approach. Using channel based filtering it is necessary to classify "packet_length > 4096" into some channel (maybe "comms.messages.warning" or similar, externally to the logging system, with less flexibility/configurability than boost.logging offers. This is one reason I'd like to be able to combine both approaches. regards Darryl.