Re: [boost] Proposed Logging Library review

From: Amit (contact.lipik_at_[hidden])
Date: 2008-02-13 09:09:28

>Hi Amit
Hi John,

Thanks for accepting my review in the constructive spirit. I am sure this
library is potentally useful enough that it has to get into boost soon. Now to
answer your questions:

> About state of log destination : basically I'll ask people to vote for 
> the features they'd like. Because I've got quite a few conflicting ones :)
> About logging exception conditions : what do you mean?

I think that if the library provides a high-level interface (i.e. provide a file
name as a log destination), then it should either provide a way to let the user
control the destination state, or explicitly state what can be assumed about the
destination. As we have discussed previously, this is specially important for
this lib since logs can be dumped asynchronously.

Also, I would think that it would be useful to have a section in the docs where
limitations, error conditions, fallback strategies are explicitly listed. E.g.,
if the destination file can't be written to due to a network failure, disk full
etc - how does the library deal with such cases? Is it an error condition to
close the destination while logging is in progress? What is the overhead of
logging using various strategies? And so on.

A suggestion is that the lib could optionally set unexpected()/terminate(), so
unhandled exception conditions can be logged. Just knowing what exception
occurred would be useful. Also, exception adapters that log automatically would
be useful. I am thinking something like: logging_exception<E> : public E where E
is a specialization of std::exception.

I see that there has been a lot of discussion about macros. My point was that
macros provide a shorthand for some instantiations/function calls. So OK to
provide macros as a convenience, but the architecture should be such that lib
can be easily understood/extended without macros as well. And doc should list
examples without macros, but mention at the end that a macro can be used instead
for brevity. This lets the reader understand what the library is doing.

Now, if only people would think about the phrase 'learning curve' and realize
steep implies good... :)

Best
Amit