"John Torjo" <john.lists@torjo.com> wrote in message news:41868F4A.1030406@torjo.com...
[snip 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?
You are definitely closing in ;-) I don't have so much spare time exactly right now, sorry. I'll try to elaborate ASAP.
Using message id's would also facilitate localization,
which would be a good thing for end-user visible logging.
How do you envision this?
Use message id's instead of literal strings in the interface. Postpone id -> text transformation until "append-time". Once you've got a formatted message it's much harder to translate it. Note that I'm only talking about the "human-readable" part of the log item - not including the modifier stuff (time, thread id, etc).
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.
Yes, I've got no objections to the name of the macro. Perhaps BOOST_LOG_MESSAGE would be even better, but you'd quickly get fed up writing that.
For example, having BOOST_CHANNEL to do logging - it seems kind of misleading.
That would definitely be a bad and misleading name.
Any better name out there?
- This opinion is probably not shared with others, but I'd prefer the
The macro name is fine with me at least. 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).
Ignore Boost.Thread, that is?
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)
"thread" above refers to Boost.Thread?
Clearly needs Boost.Thread or thread support in general?
thread support. You can override it - with your own mutex and lock
classes. And thread classes/functions (as used for e.g. the ts_appender thread)?
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'd prefer not to (of course). How about a light-weight implementation for Win32 and Posix threads?
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.
It's actually pretty complex. From the top of my head (as I said, it's been a while since) you basically need to: - Create a message resource from a message definition file (using mc.exe) - Create a dll to hold the resource - Register an event source in the registry where you define where your message resource dll is located. - When you log a message, use the source and message id, add any insertion strings as an array of strings. Regards // Johan