[Development] Qt Playground - Updating Daemon/Service Support

[Lukas Geyer]

Am 27.11.2012 08:50, schrieb Sascha Cunz:
>> 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).

I doesn't matter if it is the majority or not. It is quite a common use 
case so it has to be supported.

If your service doesn't need it, don't use it.

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

The difference is that 'operate' and 'configure' are two different tasks 
and thus usually require two different interfaces.

The 'operate' interface of an anti-malware service is to monitor data 
and network traffic. The 'configure' interface is most probably a 
seperate application which allows for tweaking the service parameters.

The 'operate' interface of a web server is to listen on a specific port 
and hand out data when requested. The 'configure' interface is most 
probably a seperate application or a configuration file which allows for 
tweaking the service parameters.

It is quite unlikely that a service has either just the one (does 
something which can't be configured) or just to other (does nothing 
which can be configured). And it is quite unlikely that a service has a 
single interface for both tasks.

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

How can QIODevice be generic? Or QDataStream? Or QTcpSocket? Or signals 
and slots?

Of course the concrete implementation is application-specific, but the 
task 'service / client communication' is quite generic.

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

Qt already allows to serialize any datatype known to the meta type 
system, provides means for IPC (D-Bus is just one example) and has a 
code generator which implements our objects (moc) and allows for 
handling asynchronous signals and slots.

So in principle I don't see a reason why Qt shouldn't or couldn't create 
stub implementations of the shared Q_INTERFACE which uses IPC to 
communicate across process boundaries.

You are right, this is not directly related - or bound to - the 'Daemon 
Framework'; but I'm in any case forced to use IPC when creating an 
interactive service.


regards,
Lukas