[Qt5-feedback] TLC for QtService...moving it into Qt5
Craig.Scott at csiro.au
Craig.Scott at csiro.au
Wed Jun 8 03:28:12 CEST 2011
On 08/06/2011, at 4:17 AM, Per Inge Mathisen wrote:
>
>> The new implementation should likely use a different name - e.g. QService, QDaemon, or
>> QDaemonService - to be more consistent with existing names of parallel
>> functionality - e.g. QCoreApplication, QApplication [5]
> ...
>> I am going to formally propose we use QDaemonService for the name of the new
>
> I would suggest QServiceApplication, since it parallels the other
> options (QApplication, QCoreApplication) nicely, and the word "daemon"
> is a bit too tied to Unix roots. But this is probably the least
> important issue :)
I agree, the name QServiceApplication would fit better with the proposed design. Personally, I'd prefer a design that let people still use a QCoreApplication and the service functionality was done after that, but this might not be so easy. If no special command-line arguments are needed/supported, then I'd question whether you really need to subclass QCoreApplication to do what is needed. If you can allow people to stick with using QCoreApplication, it will probably feel a bit more natural to Qt programmers.
>> QDaemonService will be a formal object like QApplication and QCoreApplication,
>> and should set up the application environment in a similar manner. That is, the
>> command-line options provided should be available via calling
>> QCoreApplication::arguments(). It should also have a function to tell the
>> program whether it is the formal service or the controller so that developers
>> can interact in both modes - thus being able to interact with the command-line
>> as necessary.
>
> I do not think inter-process communication by hard-wired command line
> arguments was a good design. Instead, I'd rather that on Linux systemd
> or upstart are used, if available, otherwise a generic dbus interface
> is used;
For better portability, if possible I'd suggest avoiding relying on DBus for now until it makes it into the LSB. I also agree that the hard-wired command line arguments approach was not so great. Better to integrate with the native system on each platform where possible so that users don't have to learn a new way to control the service.
> on MacOSX launchd is used; and on Windows... whatever it used
> in QtService, I suppose.
You can manage services in Windows by going to Start -> Right-click on "Computer" and select "Manage". From there, you can start and stop services, etc.
--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia
More information about the Qt5-feedback
mailing list