Getting caught up again...
----- Original Message ----- > From: Lincoln Ramsay <[email protected]> > On 01/31/2012 05:08 PM, ext Jordi Pujol wrote: >> - Crazy idea : allow logging to a socket ? ( remote log/debug ) >> - More than one logging file ? One file for every category / group of >> categories >> - Log File rotation > > Good ideas... but I think I'm against the idea of shoving all sorts of > clever "output handling" logic into qLog because you can override the > debug message handler and do all sorts of clever stuff in there. +1. The core logging facility should not have anything to do with output of the data. For work we wanted to output to syslog; but I use a lot of Qt stuff, and generate logs messages with Signals to a central logging object. The initial version turned into a mess when someone added support for Windows Event Log and file output; so I rewrote it using C++ to my advantage; and I had thought several times about proposing something similar for Qt, which this discussion seems to now be doing. The design was relatively simple: A single log object that dealt with receiving log messages via a Signal, and managed a series of back-end output log modules. The back-end output log modules had as standard interface defined by an abstract class. The log object had a default back-end selected depending on the platform; but this could be overridden by the configuration.so that one or more back-ends were in use at the same time; all backends got the same log data in no specific order. The log object itself didn't care about the output - it just managed getting the log messages; the output was up to the back-end modules. I did several for our uses: (i) syslog, (ii) Windows EventLog, (iii) C/C++ File logging, (iv) Windows File Logging. Mine were all compile-time driven - all were compiled in, and then you selected which via the configuration. For Qt, it'd probably be better to have a platform default built-in, but then also have the ability to load them from a plugin folder as a QPlug-in. I would also suggest that the plugins use a standard public interface class such as QAbstractLogFacility, like QTcpSocket uses QAbstractSocket - so that people can add their own custom logging output easily; and I would suggest that syslog and Windows EventLog be supported by Qt directly too; though only be available on the platforms that support them - e.g. you can't write to the Windows EventLog from Linux; nor to syslog from Windows (though that would really be useful). > I'm almost tempted to say that qLog should stick to the "categories" > stuff and leave all "output handling" to something else (perhaps living > in an Add-on). I did a ENUM for my system that was modeled on syslog; but it would probably be better to do something in the meta-data framework of Qt and have a sane set of initial values (syslog could probably be a good model there). $0.02 Ben _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
