[Interest] Qt5: Status of, "Add QtService to Qt proper"

[BRM]

> From: Andrew Stanley-Jones <asj at cban.com>

>Subject: Re: [Interest] Qt5: Status of, "Add QtService to Qt proper"
>Hey Guys,
>
>Before this ends up in Qt5 we have to deal with the name conflict.
>QtService way to easily confused with Qt Service Framework.  There's
>already a suggested rename of SFW to Qt Service since everything in Qt
>is a framework.  But in either case, renames are costly for everyone
>involved.


The naming conflict was part of the discussion prior.
IIRC, it wasn't quite decided but I was leaning towards QDaemonApplication.


>On Tue, Nov 20, 2012 at 4:14 AM, Charley Bay <charleyb123 at gmail.com> wrote:
>>>> Last June there was a thread with the title, "Add QtService to Qt
>>>> proper" that discussed some tender-loving-care required to update
>>>> "QtService<>" to support Qt5.
>>>>
>>>> RECALL that "QtService<>" is a template add-on (not in
>>>> Qt-proper) that
>>>> targeted Qt4, and talk was to make it a non-template, and to add it to
>>>> Qt5-proper, probably in the "network" module.
>>>>
>>>> Original thread starts here:
>>>>
>>>> <http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-June/000449.html>
>>>>
>>>> Some other feedback discussion here:
>>>>
>>>> <http://comments.gmane.org/gmane.comp.lib.qt.qt5-feedback/76>
>>>>
>>>> QUESTION:  Where did this end-up in Qt5?
>>
>> Ben respondeth:
>>> Simply put, I haven't had time to work on it.
>>>
>>>> If someone wanted a "QtService<>"-type thing (service/daemon) in
>>>> Qt5, what would be the recommended approach?
>>>
>>> I don't know if the original QtService<> Component would work with Qt5; however, I'd love to work with you and anyone else that wants to do what I originally proposed with an adjusted target - perhaps 5.1.
>>
>> I might be able to help with that.  There's enough discussion on the
>> web about the value of a "QtService" thing (and its companion
>> classes), that:
>>
>> (1) It has cross-platform value for many users
>>
>> (2) I think it should end up in Qt "proper"
>>
>> (3) I think your previous thoughts on this (and the in-depth
>> discussion on the email list) was well-thought-out.
>>
>> For the casual reader, Ben has a couple blog entries on this topic,
>> the latest one that I can find (which references a previous one) is
>> at:
>>
>> <http://clocksmind.blogspot.com/2011/09/qt5-introducing-qdaemonapplication.html>
>>
>> Just so I understand, at a HIGH LEVEL, is the scope intended to be:
>>
>> (?a) EASY TO USE.  Provide an easy-to-use API (like QApplication or
>> QCoreApplication) that implements a "service/daemon" in a
>> cross-platform way (e.g., Win/*nix/etc).  This implies a "blocking"
>> execution while the service runs (e.g., it's a service/daemon).


Yes, I'd really like the user (e.g. developer) to be able to create a service using the following:

int main(int argc, char* argv[])
{
    QDaemonApplication theService(argc, argv);
    myApplication theApplication;
    return theService.exec();

}

Or at least something very similar to it.

One of the main goals is to not make it be a template class like QService is now; as well as enable the service to properly shutdown.
QService presently just does a hard kill on the service process when it gets the terminate option on the command-line, so the service application has no means of waiting for anything to clean up (threads included).
It works, but the end result can leave applications broken at times very easily.


>> (?b) SIMPLE/STANDARD INTER-PROCESS COMMUNICATION.  Clients can access
>> the service/daemon in a simple-and-standard-way (e.g.,
>> reading-and-writing text to ports, etc.)


I've been on the Developer's list for a while, as well as this list. In observing the discussions over the many months, I started to think
about using QLocalSocket - at least out of the gate - to do the IPC between the daemon-service and user controller, at least for *nix.
They typically need to be on the same computer, so it seems like a good option to enforce that.


>> (?c) PLATFORM-SPECIFIC REGISTRATION.  Implementation properly handles
>> system-install/update, system-start, on-demand-start,
>> system-remove/uninstall, etc.


Correct.

Initial out-of-the-gate would re-implement the same existing command-line interface in order to get it up and going, and maintain compatibility.
Further development would add other interfaces - e.g. systemd - to integrate into other systems more easily.


>> Did I miss anything?  Is this a reasonable/fair characterization?


I think you got it as far as what I had blogged and what was discussed on the mailing list.

In what little time I did get towards trying to implement it, I had mostly been trying to think about the interface for enabling the application to manage the command-line so that a more extensive command-line could be utilized, both before and after the daemonization occurred - before so that QDaemonApplication or the main application could process the command line and decide it didn't need to run, and after so that the application could get any command-line options it needed during run-time. One main hang-up for me at the time was getting Qt5 compiling.

Ben