* What is your evaluation of the design? Introduces alot of new concepts for something relatively simple, logging. A study of the headers suggests a boostified functional style, but with lots of macros, which some developers here have no objection over. I on the other hand would like to see less, or even no macros in the public interface. A functional, lambda style logging interface should be adequate. If a macro is needed, suggest it as a work-around, but dont force it on the user in the example(s). * What is your evaluation of the implementation? No issues. Author appears to be knowlegable in the problem domain. * What is your evaluation of the documentation? Overall, I didnt like the informal style, but I was able to get the information I needed. Author tries to be too "cute" or "friendly". Author should get rid of informal comments and replace them with more professional language. An example of informal language is: "Yup, we have other examples as well. We also have a starter project." * What is your evaluation of the potential usefulness of the library? Potential is high. Would I use this library. As it stands, no. The tradeoff/benefits still suggest to me that logging requirements are too application specific, and this library doesnt change that equation. If it had a simple, boostified, lambda interface, with no macros, and no learning curve, I would probably use it. As it stands, its too complicated, with too little benefit for me to us it. Sorry. * Did you try to use the library? With what compiler? Did you have any problems? It compiled on GCC, linux, ubuntu, with some warnings, which I ignored. * How much effort did you put into your evaluation? Three hours * Are you knowledgeable about the problem domain? Yes. * Do you think the library should be accepted as a Boost library? No. I would evaluate it again, if the author would create a more boost friendly, lambda style public interface. Tom Brinkman