[Development] QLog ( Work on qDebug and friends)

[BRM]

Getting caught up again...



----- Original Message -----
> From: Lincoln Ramsay <lincoln.ramsay at nokia.com>
> 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