Re: [boost] Re: Re: logging lib, v1.3

From: John Torjo (john.lists_at_[hidden])
Date: 2004-11-01 14:32:26

<side-note>

What reader are you using? Could you have it wrap lines at 80 chars/line 
or so?

Since when I hit reply, I need to write quite a few CRs, just to see all 
your message.

</side-note>

> 
> 
>>That's an interesting idea.
>>
>>One problem that I see with the above taking place in another thread is 
>>that you don't know when it'll happen. This does not play well with:
>>- pre-pending time
>>- pre-pending thread ID
> 
> 
> I basically was thinking about log "messages" as data structures, 
consisting of least one message id (possibly consisting of facility,
severity and the id itself, similar to COM hresults and VMS status codes)
+ insertion data. Logging a message would include creating an instance of
a log item and storing it in the TSS buffer for later retrieval,
formatting and writing by the worker thread. Data such as timestamps,
thread id, etc is added at this point and can be selected for
inclusion/exclusion in the actual writing on the back-end instead.

So basically, after a message is added, a log_item is created, and 
different modifiers can fill different things of this log_item itself.
Then, the appender(s) will decide which information to write to the real 
destination(s). This is an interesting idea.
You could then pass a format string to the appender - kind of like log4j.
This will complicate the design - but it seems to worth it.

Is this what you're talking about, or am I totally on the wrong track?

> 
> Using message id's would also facilitate localization, 
which would be a good thing for end-user visible logging.

How do you envision this?

> 
> 
>>Whenever you add an appender/modifier, you don't specify which log it 
>>will be added to - you specify a logs_specification, where you can use 
>>the * wildcard (same goes for enabling/disabling).
> 
> 
> Maybe it's the word "log" that confuses me. For me a log is more the final destination; e.g. 
the event log, a file, etc ... In this case it is more like a channel 
for log messages, or?

"log" seems to mean different things to different people ;)
However, having the BOOST_LOG macro seems to be quite straightforward to 
people.

For example, having BOOST_CHANNEL to do logging - it seems kind of 
misleading.

Any better name out there?

>>
>>>- This opinion is probably not shared with others, but I'd prefer the library to be independent 
>>
>>from the Boost Thread library. The dependency feels kind of the wrong 
>>way around.
>>
>>This dependency is only if you use threads yourself.
> 
> 
> Naturally, but that alone might be enough to make some people 
refrain from using it. I'd prefer not having to add the
boost thread library to my dependencies simply because
I want to log message in the background. Also, there might be special
circumstances when you'd like to log messages from system invoked routines,
e.g. Win32 completion routines/APCs/console control handlers,
Unix signal handlers, VMS ASTs, system thread pool callbacks etc...

True. Well, it's not that complex to remove the dependency on 
boost.thread (that is, have a certain directive, which if turned on, to 
ignore threads).

The problem I have now is how to update the jamfile, so that it will 
generate the following:
- static lib + multi-thread runtime + using thread (already done)
- static lib + multi-thread runtime + not using thread (problem here)
- static lib + single-thread runtime + not using thread (already done)
(not sure if this is just an MSVC issue)

> 
> Clearly needs Boost.Thread or thread support in general? 

thread support. You can override it - with your own mutex and lock classes.

However, I do need to refine the log-manager concept. Also, if you 
provide your own mutex/lock classes, you might need to include the log 
source files within your project.

>>
> 
> 
> I believe that it's not so simple to integrate with the 
> NT event log as the current Boost.log is entirely based on pre-formatted strings. 
> The event log is more based on message id's, insertions strings and 
> message resource dlls, IIRC (long time since I used NT event logging).

unique IDs are not hard to generate. Anyway, I haven't used NT event 
log, but I don't think it should be very difficult to use.

Best,
John

-- 
John Torjo,    Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- http://www.torjo.com/win32gui/
-- v1.5 - tooltips at your fingertips (work for menus too!)
    + bitmap buttons (work for MessageBox too!)
    + tab dialogs, hyper links, lite html