[Interest] Qt5: Status of, "Add QtService to Qt proper"
bm_witness at yahoo.com
Tue Nov 20 15:19:24 CET 2012
> From: Andrew Stanley-Jones <asj at cban.com>
>Subject: Re: [Interest] Qt5: Status of, "Add QtService to Qt proper"
>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
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:
>>>> Some other feedback discussion here:
>>>> 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
>> 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);
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.
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.
More information about the Interest