-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Caleb Epstein Sent: den 19 december 2005 16:41 To: boost@lists.boost.org; Gennadiy Rozental; John Torjo Subject: Re: [boost] [Review] Boost.Logging: formal review

I personally prefer the all-enclosed macro style for this reason as well as others. But I think one of Gennadiy's points is that the primary interface to the Log should not be defined in terms of macros. A standard set of macros can be provided by the Boost.Log implementation for the sake of convenience and casual use. But there should be a well documented public interface that users with more complex requirements can use to write their own logging macros, in whichever style they prefer.

Yes, this is a must. The "basic" interface should be quite minimalistic and simple to use. The interface should not have any domain specific nor "too much preferred logging styles". For instance, I don't think that Gennadiy's entry keywords belong directly in this interface. There would always be a domain or user that wants specific details to be added, details that might not be a concern at all in my application. However, an entry keyword should still be very simple to "implement/use" on top of the basic interface.

I don't think it makes sense to require a user to have separate loggers to handle e.g. DEBUG, WARNING, and ERROR levels. I also don't think it makes sense to require separate logs for different logging keywords (I think thats the term Gennadiy used). The user may use separate loggers for each of these separate logical channels, but it should not be a requirement.

I'm not saying that this is required. I'm saying that it should be possible. I guess what I am saying is (like my paragraph above) style should be left to programmers and not be enforced. Especially, a logger must be able to have zero, one, or several, sinks (appenders) attached to it, and I think that that is something that you have addressed later in your post.

IMO it is very important for an administrator/programmer of a system to

...

be able to enable/disable logs, know what loggers and appenders exists and be able to configure said entities.

But if the programmer has to provide a separate logger for each logging level and conceptual channel of log information, each of which is configured independently, isn't this management problem far worse?

I suppose it could be a management nightmare and if this is the case, one would need to have fewer loggers (or one if you like), in which case a logger is not tied to a specific log level (e.g.). And in this case, the programmer would use whater log functions deemed necessary to make the job simple(r). However, I'm not sure such functions should be part of the logger interface, but could be functions/macros that depend on the loggers and not vice versa in order to minimize the logger's interface.

If filter is only done on a per log statement, how do you even know as a

...

administrator of a system what log filters exists? Which filter criteria should be enabled and which filter criteria should be disabled?

Can you expound a bit on what you mean by this?

Well, with a development team of 20+ people I might want to tightly control what is being logged and that all "important" log messages are sent to a specific sink. If entry keywords are used, for instance, I'm quite sure that the number of keywords in use probably would explode. Which of these are important and which are not so important? Which are warnings, which messages should be filtered and so on. Perhaps I want to enable all log messages with a the specific entry keyword "my_special_condition", but what happens when a programer misspelled this keyword. This could also turn into a management nightmare IMO (unless I'm totally misunderstanding the concept). If a systems architect would like to send specific log message to specific sinks, wouldn't this be a management problem as well? I would still have to setup and configure loggers/filter/sink combinations. I'm not sure there is a "better" solution to this general problem. It's a difficult problem and should be treated as such. IMO, there must be several ways to solve the issue, chosen by programmers and teams that suits their specific "design" choice. This boils down to, IMO, to simplistic loggers and sinks, and a more "complex" extensible layer on top of this, perhaps provided by the library for common situations..

I see the central concepts as:

Entry (or Message): the set of information that makes up a single message to log. Might include a "level" (e.g. debug, info, warning, error), a "category" (e.g. arguments, program_flow, etc), a "keyword" (e.g. "Network", "UI", "Disk Cache", etc) and of course a text string.

Could be more or it could be less in specific situations. But other than that I agree with you.

Filter: determines whether or not an Entry should be logged. Probably implemented as a relatively simple functor. Sink: ultimate destination for Entries. Implementations for wirting to files, system log facilities, etc can be provided. Log: provides logging methods. Implements the Filter concept and contains zero or more Sinks which are the targets of Entries for which the Filter returns true.

I aggree with you on a conceptual level. However, the Filter concept shouldn't be part of, IMO, the logger. Or if it is, at least, there should be an alternative interface in the logger, or possibly, the filtering concept should be very simple if I don't want entry keywords and such. Fundementally, I think that writing log statements and filtering log statements are two different and orthogonal concepts. Filtering is an efficiency decision at the conceptual level. With that I mean if we had infinite computing power (which we don't) filtering wouldn't be necessary at all when sending log entries to sinks. Filtering is however something the target audience does when looking for, or at, log statements. That is, with infinite computing power, the filtering mechanism could be done at the time when administrators/programmers are looking/searching logs. But since we don't have infinite computing power, log entries need to be filter before sending them to sinks (I suppose one could argue that there are other reasons for filtering before sending entries to sinks; but I don't see a difference). So the interface for enabling/disabling log entries should be a fundemental concept to a logging library and obviously as well designed as the actual log entry interface. Especially, wether to send a log entry to a sink should incur minimal overhead, or else risk efficiency even if the log statement are not sent to the sinks. This is especially true if programers use many log statements. IMO at the most fundemental layer, a logger is either enabled or disabled. If it is enabled, log entries are sent to its attached sinks. Filtering should be implemented on top of loggers. The filtering concept determines wether to send the log entry to the logger or not.

I've been sketching up a very simple implementation of some of these ideas in my spare time. Is there interest in fleshing these ideas out more fully on or off-list?

Cool! Yes, very interested (I have myself an implementation... who doesn't ;-)) /Richard The content of this e-mail is intended only for the confidential use of the person(s) to whom it is addressed. If the reader of this message is not such a person, you are hereby notified that you have received this communication in error and that reading it, copying it, or in any way disseminating its content to any other person, is strictly prohibited. If you have received this message in error, please notify the author by replying to the e-mail immediately. NeoNet AB and its subsidiaries (NeoNet Securities AB, NeoNet Securities Inc. and NeoNet Technology AB) are unable to exercise control over the content of information contained in transmissions made via the Internet and hereby excludes any warranty as to the quality or accuracy of any information contained in this message and any liability of any kind for the information contained in it, or for its transmission, reception, storage or use in any way whatsoever.