[Development] Qt Playground - Updating Daemon/Service Support

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

> 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.
I've written quite some services that just plug into a fixed database and get 
all they need from there...

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

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

Sascha