Jody Hagins wrote:
I'd avise both of you to look at John Torjo's library, and read the review comments. John pulled the library, but it would benefit you greatly to see what others thought, and more specifically what they want in a boost logging library. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thanks Jody, we should definitely avoid starting from scratch again. The problem is that there is so many divergent propositions and ideas, and aggregate them won't be an easy task. Here is a couple of ideas I have glanced from previous threads: John Torjo had actually a similar point of view to mine. He was looking for simplicity. As we are talking to a wide range of users, the library should have almost no learning curve. Looking at the basic example in the tutorial should be enough to get the fundamental usage of it. John had also in mind the possibility to disconnect module of application from the logger. For example, from a certain point in the code, the GUI logs would be discarded. He also wanted the library to be small, and I fully agree with this. A header file and that's it. Not anyone agree with this, Vladimir Prus for example was expecting something more configurable. Pavel Vozenilek added: "Maybe it is possible to design a library which has (by default) this simple interface but allows very fine customization." That is why I'm trying to concentrate on the first part (design a library which has (by default) this simple interface) and then, a second part could be handled by other people interested in fine customization. As a first set of requirements, Caleb Epstein stated those, and Rene Riviera answered: <CE>: Uses iostreams <RR>: I disagree. Like most things STL it should be independent of a stream back end. And ideally independent of a formatting front end. It should only be a tagging, filtering, and multiplexing interface. <CE>: Thread-safe (e.g. two threads can't have their output intermixed in the output file/stream/whatever like they would with simple ostream<< operators) <RR>: Yes, but only if needed. It might not be appropriate depending on the front end or back end. For example you might be dumping the "output" to a database which would create individual debug records. No need for thread safety at the log level in that case. <CE>: Multiple possible output media (files, sockets, syslog, Windows event log, etc) RR: Multiplexing <CE>: Multiple named channels each with configurable "threshold" (e.g. error, warning, debug, etc) <RR>: And configurable, so that you can program what each one does on both the front end and to which back end they go to. <JD>: The log level (unsigned short) could handle that. OR maybe a mask would be more appropriate ? <CE>: Messages which won't be logged shouldn't even go through the formatting step. I'm pretty sure this cannot be done in a single call w/o macros though. Johan Nilson also engaged a lengthy discussion. Few ideas I have retain from him: Structured logging functionality. (<JD>: Is it formatting you are talking about?) log_item for formatting (<JD>: What I called log_element in the library I have posted). Daryl Green seems to have a put a lot of though into this and also define a set of requirements I'm trying to summarize here, some of them are pure citation: - The logging library must be very efficient in handling disabled "logs". - The logging library must be user extensible to add new output (appender) facilities. This should be very easy and not require in-depth knowledge/study of library/its docs to do. Appenders, which are likely to have system dependencies, should not be tightly coupled with the core logging facilities. (<JD>: Wishful thinking ?) - The library must scale well. This should include the ability to (efficiently) use a very minimal form of the library in small, perhaps single-threaded only, apps as well as achieving good performance on multiprocessor platforms in multi threaded apps. (<JD>: The first part I was talking about, but the multi threading shall not be an option for me). I agree also with Daryl that a very simple, extensible library can be submitted first and extended in the future. If we wait for a complete logging library to introduce it into boost, we'll never have it... Maxim Yegorushkin asked for file management (cycling through log file, file size control). I think this is interesting but shall not make it into the core library. Maybe an helper object, in a distinct header file could make it. Still I think this shall not be part of the first line of proposal as it tends to divert the discussion and prevent decision on the core logging library itself to be taken. Some few ideas I saw: + Scoped log (<JD>: what is a scoped log?) + fast compile time Technical questions: + thread id: How to retrieve thread id with Boost.Threads? + program name: Is argv[0] a good idea to retrieve program name? I don't why i wouldn't, but just in case. Now, some point raised during the formal review of John's library: - Roman Yakovenko: He was not pleased by the way John's library handles macro. In this library, here is the way you log something: BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; In any case, logging avtivated or not, the message will be streamed. What I developped in the logging library posted above is to encapsulate the streaming in the macro, as propose by many people during the discussion: BOOST_LOG(1, "this is a debug message, i=" << i << std::endl); The streaming will be performed only if necessary. Note, the library I posted does not handle it correctly (the test is perform after the streaming ;p), but it will. I also see the need of a compile time disabling. Here again, I'm not sure the library shall deal with this. Just define some macro like: BOOST_LOG_L1(trace) BOOST_LOG(1, trace) BOOST_LOG_L2(trace) BOOST_LOG(2, trace) #ifdef _DEBUG BOOST_LOG_L3(trace) BOOST_LOG(3, trace) #elseif BOOST_LOG_L3(trace) ; #endif // _DEBUG - Andras Erdei: "My main concern about logging is that it changes application behavior: 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." So another requirement would be that the library shall be as fast as possible (pretty obvious) and the less intrusive as possible. But I'm afraid the caveats described by Andras are inevitable. "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" Well, I think the initialization part is essential, or you have a library that is deciding things for you, and I don't think it's a good thing. " and i do not want to pay (with runtime and additional typing) for the features i do not use." Seems fair. -> Library shall stay simple. The more simple it is, the more it has chance to get into boost and then be developed to something more evolved. To Andras remarks, John answered: " 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." I think this is where troubles starts. As I said, the logging library shall be simple to the cost of not being configurable at first. After inclusion to boost, it can get better. Yes, it looks like petty politics, but how come there is no logging library into boost with all the interest it has in the past then ? JD