[Development] Qt Playground - Updating Daemon/Service Support

BRM bm_witness at yahoo.com
Mon Nov 26 19:18:40 CET 2012


> From: Matt Broadstone <mbroadst at gmail.com>

>On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay <charleyb123 at gmail.com> wrote:
>
>>>> <snip, updating the "QtService<>" Component >, 
>>>>> I would like to open a new Qt Playground project to create a new equivalent
>>
>>
>>+1
>> 
>>IMHO this would be a cross-platform useful module that I'd vote to ultimately end-up within "Qt-proper".
>>
>>
>>Disclosure:  I traded emails with BRM off-list, and would like to help.
>>
>>--charley
>
>Would you guys like to get into your design a little here? Did you mean that you would be creating two classes: QCoreService/QGuiService (though I'm not sure why one would want a gui service, maybe to use some of the graphics classes?). Also, could you speak to your ideas for the pluggable backend? Will you target systemd as a reference implementation? 
>


Design is relatively simple. There will be 1 public class - initially DaemonApplication (add Q when it becomes part of Qt, following Playground rules). Daemon/Service writers can then do:

...
#include <Daemon/DaemonApplication>
...


int main(int argc, char* argv[])
{
    DaemonApplication theDaemon(argc, argv);
    ...
    // Create your application instance here - just like with QCoreApplication/QApplication.
    ...

    return theDaemon.exec();

}

Inside DaemonApplication there will be a private object that provides the daemonization support, command-line support, etc. It will also use a QLocalSocket to manage the communications between the Controller and Daemonized instances. The user level application should only need to be aware of the various transitions - start/stop, pause/resume - and be able to tell the internal that it succeeded, failed, needs to delay, etc in response to those. (E.g. the application needs to shutdown properly, so a QEvent will need to be there to approve, delay, or deny the shutdown.)


There will be signals and events from DaemonApplication that applications can use to manage the various transitions, etc.
For instance, there will be a pre-daemonization stage where DaemonApplication will need to notify the user application so it can process the command-line in case that needs to stop the daemonization process.

Ultimately I want to stick very much to the KISS principles in the design.


Many details are still left to work out, but that's the basic idea floating.


Ben




More information about the Development mailing list