Re: [boost] Logging Library -- Formal Review Request

From: John Torjo (john.lists_at_[hidden])
Date: 2005-05-04 04:30:33

Hi Andras,

Many thanks for the pre-evaluation!

>
>* What is your evaluation of the documentation?
>
>It is too brief.
>
>  
>
Yes, indeed, I do need to provide more examples, usage scenarios, etc.

>* What is your evaluation of the design/implementation?
>
>I would like to see three components:
>
>- the viewer application on John's page should be officially part
>  of the library, with the option of running it as a separate
>  application/running it as a thread in the application being
>  developed
>  
>
No problem there ;) However, you should note that at this time, the 
viewer application is Windows-only.

>- the current libary should be split into a logging primitives
>  (building blocks) part
>
>- and into several "..._style_log.hpp" interfaces, supporting the
>  different styles and bells & whistles and different default
>  settings people ask for
>  
>
This is an interesting idea. In the future, I want to ask people to 
provide me with different scenarios in which they use logging. This, 
based on how many such scenarios I find, could then end up into what you 
say.

>My main concern about logging is that it changes application
>behaviour: often there are bugs that only surface in release code
>because logging is slow and it introduces synchronizing, so logging
>should be as fast as possible, and locks should be avoided whenever
>possible.
>
>  
>
Locks are avoided whenever possible.

>My style would be:
>
>Appenders: do not cache and do not use a dedicated writer thread,
>but each thread automagically creates it's own separate logfile.
>The files are kept open, flushed after each log entry, and the
>streams used for formatting the log entries are kept and reused.
>The log files are created in a system-dependent directory (e.g.
>%TEMP% on windoze), and the logs from the previous run are removed
>automagically.
>
>Modifiers: a global counter prefix, an indenter and a clock (secs
>elapsed since application start); and source file name, line number
>postfix.
>
>I do not want to declare and define and initialize logs, just
>include a header, and then write "LOG << ..."; i do not want
>to give names to logfiles, and i don't want runtime configurable
>logs and log levels and multiline log entries and calling functions
>that log from inside "LOG << ..." statements and i do not want to
>pay (with runtime and additional typing) for the features i do not
>use.
>
>  
>
Ok, so we could say we have the first scenario ;)

>I think a lot of the current library functionality can be moved
>into the viewer: it can merge the per-thread logfiles or scatter
>log entries based on a prefix (thus no need for named logs and
>different threads writing the same file), it can calculate entry
>times from the file creation date and clock stamp (to avoid time-
>consuming date formatting modifiers) etc. Also, having indentation
>in the logs allows the viewer to display the log contents as a
>tree-view making log browsing much simpler.
>  
>
Yes, that's the reason I created the viewer. However, I made the logging 
library flexible (or at least I hope so :)), so users can tweak the lib 
to their needs.Logging can be so much more that writing to one file.

>* Do you think the library should be accepted as a Boost library?
>
>Not yet, i would rather put a link and a strong suggestion to use it
>on the boost webpage, and include it in boost only after it has been
>used in several projects.
>
>  
>
Sure thing ;) Note that I have used in in a quite a few projects (more 
than 6, I think; from which 2 projects were quite large), and have 
received (private) feedback from other people who have successfully used 
it in their apps.

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.6.3 (Resource Splitter)
-- http://www.torjo.com/cb/ - Click, Build, Run!