[Development] Qt Playground - Updating Daemon/Service Support

[BRM]

> From: Lukas Geyer <lgeyer at gmx.at>

> Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
> Am 27.11.2012 11:03, schrieb Sascha Cunz:
>>  [...]
>>>  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.
>>  I don't oppose to all of that. Just that it has to happen through a
>>  QLocalSocket. As soon as I want to configure such a service remotely, I'm
>>  bound to rely on SSH-tunneling or such. In that case I'd want to make that
>>  interface TCP based and add authentification to it. If - like originally
>>  suggested - the 'daemon framework' provided us with the QLocalSocket
>>  restriction, I had no easy way doing that.
> We've been clearly talking past each other here.

Yes, you have.

> Yes, the interface should not be restricted to QLocalSocket. Whether the 
> interface is locally or remotely accessible is an implementation detail 
> of the application, not the framework.

It is not the place the Daemon-Service API to provide the means to configure the daemon.
Personally, I think the use of QSettings to a file/registry should be sufficient, and
if the developer wants a GUI interface they can add one using their own protocol specific to their
application.

So I consider that to be out-of-scope for the Daemon-Service API.

The Daemon-Service API is solely focused on the daemonization process of an application.
And a Daemonized Application very specifically - by modern OS requirements - cannot have a GUI.
 
The use of QLocalSocket is solely for the internal communications between the Daemon Controller
and the Daemon itself. Where the Daemon Controller will provide the required interface to interact
with the various OS systems - whether Windows SCM, systemd, etc.

Even in Windows the Controller interface does not normally directly access the Service; rather it
is an independent instance of the application that runs and responds to the SCM, then sends
IPC messages (e.g. events) to the actual running service application.

The same is true of Linux daemons, only the interface is typically command-line driven.
For instance, look at how Apache's apachectl and httpd talk to each other.

>>>>  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.
>>  By all means then, find someone to implement it. Could turn out to be yet
>>  another shiny gem in the bag of Qt-Evangelists.
> If you build it, they will come.
> 
> Having a standardized way for cross-process events (what queued signals 
> and slots basically are) would be a valuable addition, not only to the 
> 'daemon framework'.
> 
>>>  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.
>>  Here we come together again...
>>  Because this was, what I initially wanted to say:
>> 
>>  1. We don't need to communicate with the daemon for administrative operations
>>      like starting / pausing / stopping. We _must_ integrate into the native OS-
>>      provided meachnisms.

The integration to the native OS-provided mechanism is the Controller interface.
This is very often command-line based - no options/start/stop/pause/resume - even on Windows.

For the Windows SCM you implement a specific interface by which to get the information
that the SCM is trying to tell you, then you tell your application via your own methods what to do.
That is what the use of QLocalSocket mitigates.

Inside the actual daemon/service the application objects will be able to listen to signals/events
in a Qt-style manner.
 
>>  2. Even configuration and/or monitoring a daemon belong to the daemon's
>>      bussiness logic. This requires IPC, that much i don't disagree, but:
>>  3. Qt has already a good collection of IPC mechanisms built in (file-based,
>>      database-based, network-based, local IPC via various ways, DBUS ...).
>>      There is no need to limit us to a local-socket.

QLocalSocket will be used for one very specific internal use. The controller can integrate into
anything else - Windows SCM, D-Bus, etc - whatever is needed for the platform.

It also does not prevent the application from integrating into those things either.

So I think we're getting off on a tangent for this discussion - for the API we have to draw the line at some point.
And that, at least for now, is the Daemonization boundary.

Yes, we want to modernize who QtService component works a little by fixing some things - ability to use signals/slots, ability for applications to properly clean-up on shutdown.
However, the QtService generally had the right idea in what it did, and we want to replicate that as an official API.

That doesn't mean we can't go back after the initial round and add other features and functionality.
For now, I really want to keep it simple (KISS) - even to the point of the initial version will replicate the same command-line interface as the QtService component before we start adding other interface support.

If we do it right, then it won't matter whether we use QLocalSocket or change it out for something else later. It's not going to be part of the exposed API - it'll be a detail of the DaemonApplicationPrivate class, or the Abstract interface class for the back-end pieces that do the integration work.

Per the reference to using QGuiApplication/QApplication in a daemon, I 
believe you can use QPainter in a non-GUI thread as long as you are not 
trying to write to the main GUI thread which is primarily responsible 
for drawing on the display (no?). If I understand that correctly, then it may require those daemons to be refactored a little for the new API, but they should still be 100% possible to do. Please correct me if I'm wrong.

Ben