I posted a message about logging some days ago. Basically, I've done a patch, and needs a decision on if it should be included or not. There was no remarks on my previous message, question is how to interpret this: that everybody agrees, or that no one cares ? ;-)
Aurelien feels that this requires a discussion, so I make a new try... In short, the patch can be described like this: - At source level, compatible with current system. (No changes for files just logging.) - Under the hood, compatible with log4cxx, the C++ log4j implementation. - First step, including new files + some general fixup already checked in.( r13150) - Step two, replaces current Logger::getInstance() semantics with the log4j Logger::getLogger( "logger.id" ) model, + new configuration. - Step three, expands the interface between phapi and C++ to use the new log4j semantics. I've used my own patch for some time now, and I'll try to explain why I think it should be included despite the late date in the partly new light of my experiences. I'm doing this since I believe that the risk with this patch is small. However, using the the patch gives several advantages: - There is once again console logging. Before recent changes, we had debug output at the console, which just isn't acceptable. But now we have no logging at all, which is also bad. New system is typically configured with error messages in the console, this is great information when something happens. It *is* silent during normal use, though. Shipping without any console error logging is a Bad Thing IMHO. - Using the log4j/log4cc model means that the conceptual model is a well established design pattern. So things tends to fit. This spans from the new patch actually implementing the large commentary in our logging header, to that the phapi interface fits other frame- works using this pattern e. g., python. It fits both minds and software, that is. This aspect is important for the phapi interface. The option to use log4cxx as an backend also opens up for whatever future logging needs that might arise. - Configuration/documentation is just so much easier. Today's system with environment variables is not that easy to document, and we have to many environment variables anyway. The new system uses a configuration file, and to modify this is much easier for many users. It is also "self-documenting" to a degree, (see r13149). - Using the new system we can configure all phapi logging in runtime. This should make it easier to catch problems once the sw is used out there. Note that all phapi logging cannot be turned on by default, it just to much, and there is also performance aspects. Overall, the new system gives more information, and is easier to to cope with, for end users. So, this was a long essay. On logging(!). But I really think we should include it. And that it should be shipped with next version. Because better logging tools for the users reporting problems will save time. Or am I wrong? --alec _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
