Hello Michael, Wednesday, April 4, 2007, 5:31:29 PM, you wrote:
Andrey Semashev wrote:
I agree with Austin. I think, the "user" word is what confused you. The "user" here may be a system administrator or a technical support service specialist, for example. Such users have enough knowledge about the application that produced the log, so they are able to read it and figure out the problem. Though they are not interested in the internals of the application which only developer knows (i.e. they wouldn't understand what "i = 10, too bad :(" log record means).
On the other hand, I believe such functionality may be easily achieved with proper filtering and providing separate sinks for these types of output. Michael, do you agree with me?
I agree with your general description, but i am not sure seperate sinks are a good idea (even if they provide a way to do it). The problem is that often temporal coherence and the sequence of log messages is important to determine the root of a problem. For example: the debug message that a socket read blocked unexpectely is much more informative if i can view it in the context of log statements telling me wich client connected/disconnected. If one lands in a debug file and the other in the access log then i will need to take special steps to view them in the correct order which is undesirable i think.
The project I am currently working on has many seperate daemon programs (possibly running on different machines too), so i specifically added networked logging with a single sink, just to be able to view all the log messages in their natural order.
I see. I guess now I'm beginning to understand what channels are meant for. The channel appears to be yet another attribute which defines the "class" of the log record (i.e. an access log, debug trace, etc.). Seems to me we have to fix the set of mandatory attributes that every log record should always have and leave space for optional attributes (channels go here). I see these attributes as mandatory: - record number (increments for each record collected) - record date and time - thread name (if not set - thread id) - scope stack - severity level - message text As for optional attributes I think, it's better to leave them on user's behalf since it's too difficult to figure out the correct set of them and implement suitable interface to operate them in the unified and convenient way. But, surely, the library should leave an easy way to implement them. -- Best regards, Andrey mailto:andysem@mail.ru