Am 27.11.2012 06:15, schrieb Sascha Cunz: >> A daemon/service has two interfaces: (i) user/system-API oriented, and (ii) >> one internal. >> >> The first presents the interface to the outside world on how to control the >> service. This interface needs to integrated into the system - e.g. Windows >> Service API, systemd, shell scripting, user query. > Right. > >> However, this interface >> also needs to be able to talk to the daemonized process which has had its >> user-interface (e.g. Tty) removed from it. You can only do that using some >> form of communications - network port, message queues, etc. > > But why would it want to do that? I mean: Is there a generic gain that is not > already provided by the operating system itself?
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). 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. - 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). - 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). 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). - provide no support for the 'service' interface. - provide support to interact with the service from a (graphical) user client in a flexible, transparent way. 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. - provide support to interface with the service directly. I mean, hey, so we may finally get a suitable out-of-the-box command line parser after two decades of development ;-) On a sidenote: There is a scope for non-interactive, but QGuiApplication / QApplication bsaed services. I've seen people doing image processing or website grabbing which requires QtGui resp. QtWidgets, but no graphical interface. regards, Lukas _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
