[Development] Qt Playground - Updating Daemon/Service Support

[Lukas Geyer]

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

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

Agreed.