Hello Austin, Thursday, April 5, 2007, 5:38:14 PM, you wrote:
On 2007-04-04, David Abrahams <dave@boost-consulting.com> wrote:
IMHO, we're not talking about including it into boost, but we're looking for a proper design solutions and frequently requested useful features, aren't we?
Yes, that's right. If the design is really "perfect," we can certainly do our own implementation if need be.
The pantheios system certainly has some interesting aspects as well as some shortcomings, all of which are worth considering. Let me also start by saying that the pantheios documentation is lacking and I don't have time to read the code in depth; if I'm way off target on what I say here, someone please correct me!
[snip]
Anyhow, this is really just the briefest of reviews of pantheios. Others should probably check it out as well, but I think that it's pretty far off the mark of what the general boost population will be looking for. We might get some good ideas from it, but it needs some serious extending. Of course, some significantly better documentation would be a good step in the right direction.
After examining the documentation I agree with your review conclusions. I got the impression that many design decisions were led by the intent to be C-compatible. Some of the decisions are left unclear for me (for example, the relation between the front-end and back-ends and the way it decides which one will get the message), which, I think, is because of lack of documentation. I found no attributes (or things like that) support which seems to be fundamental for many features requested in this thread and on the Wiki page. The filtering capabilities are limited to severity level check. What I liked about the library is the set of outputs available out-of-box. The performance is better in case of disabled logging for the ability to delay formatting. Although, there is no significant difference when the logging is on. To my mind, the Boost implementation should be more extensible. It may not provide as much sink types as pantheios does, but the library should provide means to implement it. The attribute support and more elaborate filtering is a must in order to support things like channels, call stacks and log origins. -- Best regards, Andrey mailto:andysem@mail.ru