[...] > 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
