This is unfortunately delayed results review of Logging library submitted by 
<br>John Torjo.<br><br>I read through the submitted reviews and here is a short 
summary:<br><br>- 2 Tom Brinkman&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | evaluate it again, if a more boost 
friendly, <br>lambda style public interface is present<br>+ 7 Steven Watanabe&nbsp;&nbsp;&nbsp; 
| all the issues with destructors and exceptions <br>absolutely must be 
fixed<br>+ 7 Vadim&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | with some improvements to documentation 
and <br>ease-of-use<br>- 0 Phil Endecott&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | not in its current 
form<br>+ 9 Jurko Gospodnetic&nbsp;&nbsp; | seems good enough<br>- 3 Jamie 
Allsop&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | changes that are needed are too numerous to <br>warrant a 
&#39;yes and tidy-up&#39; vote<br>- 2 Christian Holmquist&nbsp;&nbsp; | the documentation is 
written with other <br>scenarios in mind<br>- 4 Sean Hunt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | 
approach is a little too generic and forces <br>the user to jump through 
hoops<br>+ 9 Arnstein Ressem&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | compiler and valgrind warnings has to be 
fixed <br>before submission<br>+ 6 Loic Joly&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | yes, knowing 
this library will probably <br>evolve anyway<br>+ 7 Paul A Pristow&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | 
expecting some quite major revisions of <br>documentation, and perhaps 
implementation<br>- 3 Amit&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Not in its current form. 
with some <br>changes library would have support<br>-1/2 Paul Bexter&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
| spread too thin<br>- 4 Scott Woods&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | logging facility should be 
targeted slightly <br>differently<br>+ 10 Bruce Sharpe&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | need exactly 
this functionality<br>- 1 Andrey Semashev&nbsp;&nbsp;&nbsp;&nbsp; | expect something different and 
more elaborate from <br>the logging library<br><br>(The number after the vote is 
my own estimation of review vote in 0-10 <br>grade). Paul Bexter did not express 
clear vote, but submitted an opinion <br>supporting Amit position.<br><br>In the 
end we came to 8 negative 7 positive votes with average 4.9 grade. 
<br>Essentially opinions split right in a middle. Oh, how familiar these days 
;)<br><br>I must say this puts me in a quite a spot. The library obviously has 
great <br>potential, but quite unacceptable by many in it&#39;s current form. While 
<br>praising it&#39;s flexibility in many aspects, the reviewers expressed wide 
<br>variety of serious concerns regarding design, implementation and 
<br>documentation.<br><br>Well, I can&#39;t delay it any more. ;) Under the 
circumstances, I prefer to err <br>on a side of caution.<br><br>The logging 
library submission is NOT accepted in it&#39;s current form.<br><br>My biggest 
concern, as many others expressed here before, is that we do need <br>the 
logging library. So I can&#39;t be any more encouraging to John to resubmit <br>an 
updated version for review within any reasonably short time, once issues 
<br>brought during review are addressed. I am not going to list all the issues 
<br>here - you will need to look through quite detailed reviews, but I want to 
<br>emphasize most prominent ones:<br><br>* The library would gain from clean 
separation of framework and solution. <br>What I mean here is that there should 
be separate<br>layer which defines only generic concepts and another layer for 
specific <br>solutions provided by library. My personal suggestion is to use 
layered <br>design, where each layer is more feature-rich, but more 
targeted.<br>* Library should support wide variety of &quot;simple cases&quot; out of the 
box and <br>with minimal efforts required by users. *Each* usage scenario should 
be well <br>documented and supported by example.<br>* Library shouldn&#39;t try to 
be too smart. All optimizations and advanced <br>features should be eliminated. 
At least not in a review version. This <br>includes any kind of optimized 
strings or scenario based log selection. <br>Later on you may start adding them 
based on user input.<br>* I recommend to start some kind of pool for 
simple/common cases on the dev <br>list before you jump to support them. Library 
should clearly state that <br>other more advanced usage cases are supportable as 
well. The same <br>recommendation applies to the general set of supported 
features by the <br>library out of the box.<br>* Macros usage should be 
marginally reduced. Documentation should explain <br>how to write them, but not 
force them as the only solution.<br>* You may consider supporting lambda like 
API an one of the alternatives.<br>* Unicode support strategy needs to be 
fixed<br>* Documentation require major revision. Obviously I can&#39;t put it as a 
<br>requirement, but my personal recommendation - drop doxigen. IMO you can&#39;t 
<br>have professional documentation based on this format. Plus it&#39;s 
<br>unnecessarily pollute your code. Boostbook and Quickbook are much more 
<br>attractive solutions. Also many reviewers expressed desire for more formal 
<br>tone in user&#39;s guide and reference. (Another personal comment - where did 
<br>you find word &quot;gather&quot; usage as noun? I personally would prefer something 
<br>like &quot;entry&quot;)<br><br>Yet again I&#39;d like to express our gratitude to the John 
for his efforts and <br>hopes that he&#39;ll be able to see this library though to 
the eventual success. <br>It has great potential.<br><br>Gennadiy Rozental<br>-- 
Review Manager --<br><br>