[Qt5-feedback] TLC for QtService...moving it into Qt5

[Per Inge Mathisen]

Hello all,

On Tue, Jun 7, 2011 at 7:39 PM, BRM <bm_witness at yahoo.com> wrote:
> A few weeks ago I proposed that QtService be integrated natively into Qt5 [1]

I support this and will gladly help out with as time permits. I fully
agree with the proposal except as commented below.

> 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 :)

> 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; on MacOSX launchd is used; and on Windows... whatever it used
in QtService, I suppose. Then individual programmers can add control
options by command line arguments, if desired, using an API that
abstracts these interfaces and adds a means of discovery whether
another copy of the process is already running. Whether to allow
multiple instances of the service should be a programmer choice.

I hope that made sense.

 -- Per