[Development] Qt Playground - Updating Daemon/Service Support

[Lukas Geyer]

Am 27.11.2012 06:15, schrieb Sascha Cunz:
>> A daemon/service has two interfaces: (i) user/system-API oriented, and (ii)
>> one internal.
>>
>> The first presents the interface to the outside world on how to control the
>> service. This interface needs to integrated into the system - e.g. Windows
>> Service API, systemd, shell scripting, user query.
> Right.
>
>> However, this interface
>> also needs to be able to talk to the daemonized process which has had its
>> user-interface (e.g. Tty) removed from it. You can only do that using some
>> form of communications - network port, message queues, etc.
 >
> But why would it want to do that? I mean: Is there a generic gain that is not
> already provided by the operating system itself?

Yes. Each service which needs to interact with the user requires some 
sort of IPC to provide a graphical interface, as interactive services 
are not allowed on most modern operating systems (not to mention design 
considerations).

Basically each service has three different 'interfaces':

- lifetime control: start, stop, restart, installation, removal and 
alike. This is (usually) not a responsibility of the service, but solely 
the system (ie. the Service Manager, systemd and alike). The 'Daemon 
Framework' may provide platform-independent means (a set of classes and 
a simple tool using those) to interact with the platform-specific 
service management system to control the lifetime of a service and to 
interact with the system to provide status and receive events.

- the 'service': which basically abstracts the task the service has been 
installed for, e.g. serving data over HTTP for a web server, scanning 
disks for an antivirus service, transferring data for a backup service. 
'The Daemon Framework' does not have to provide any support for this 
interface, as it is purely application-specific and already provided by 
other parts of Qt (QTcpServer, QFile, QFileSystemWatcher and alike).

- the configuration or user interface: which basically allows for 
interacting with the user, which might be in the simplest form a 
configuration file, but more often then not this is full-blown 
application to do service-specific tasks, be it the user interface for 
the antivirus service (configuration of the scan engine, add and remove 
localtions, on-demand scanning and alike) or the backup service (add or 
remove jobs, on-demand backup and alike).


As a user (as in 'using the framework to develop service applications 
and user clients') I expect (as in 'I would like to see') from the 
'Daemon Framework' to:

- provide a set of classes which allow for interacting with the 
system-specific service manager, both from the service application 
(report status, request reload or restart, notification of system events 
and alike) as well from the user client or a configuration or 
installation utility (start, stop, restart, install, remove and alike).

- provide no support for the 'service' interface.

- provide support to interact with the service from a (graphical) user 
client in a flexible, transparent way. In its 'simplest' form this is a 
Q_INTERFACE implemented on the service side and generated on the client 
side, which automatically routes all signals, slots, properties and 
method calls to the service application using some kind of (local and 
non-local) IPC. If needed, I expect to be able to 'go deeper', selecting 
a specific IPC method, directly accessing the IPC and alike.

- provide support to interface with the service directly. I mean, hey, 
so we may finally get a suitable out-of-the-box command line parser 
after two decades of development ;-)


On a sidenote: There is a scope for non-interactive, but QGuiApplication 
/ QApplication bsaed services. I've seen people doing image processing 
or website grabbing which requires QtGui resp. QtWidgets, but no 
graphical interface.


regards,
Lukas