[Development] Qt Playground - Updating Daemon/Service Support

[Sascha Cunz]

Am Dienstag, 27. November 2012, 08:16:20 schrieb 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).
As you said: this applies _only_ to those that "needs to interact with the 
user". These are not the majority on the operating systems I use (Windows and 
Linux, mostly).

> 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.
Agreed.
 
> - 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).
Agreed.
 
> - 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).
Where is the difference to the previous bullet?

> 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).
That would be awesome to have!

> - provide no support for the 'service' interface.
Agreed.

> - provide support to interact with the service from a (graphical) user
> client in a flexible, transparent way.
How can this be _generic_? This stuff obviously belongs to the bussiness logic 
of the daemon/service.

> 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.

This "simplest form" describes an IPC technique that is currently not deployed 
in Qt. It would be cool to have it, but it has nothing to do with a 'Daemon-
Framework'. What you describe here sounds to me like something between DBUS 
and COM, readily tailored towards Qt's singal/slot mechanism.

Another thing that comes to mind would be a towards-Qt-tailored implementation 
of Google's protobuf [1]. But again: This isn't service-specific.
There are use-cases for 2 desktop-apps to talk in that manner to each other. 
Just think about Microsoft's "PDB-Server", which is acutally a background 
process (but not as fullblown to be called "service") that the IDE, Debugger 
and Compiler use.

> - provide support to interface with the service directly.
Well, again, I don't think that a "daemon-framework" should force a specific 
way of interaction to the user (=developer).

> I mean, hey, so we may finally get a suitable out-of-the-box command line
> parser after two decades of development ;-)
Yes, please! :-)

> 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.
Sadly, that's true. IIRC, on Windows a services needs to have special security 
attributes to even allow a SysTray-Icon to be displayed. But OTOH, I don't 
think that a service should do that.

Sascha

[1] http://code.google.com/p/protobuf/