----- Original Message ---- > From: Thiago Macieira <[email protected]> > Em Tuesday, 7 de June de 2011, às 10:39:15, BRM escreveu: > > It has been proposed to make a new QtService implementation that makes use > > of C++ Abstract Interface classes instead [1,3]. In the process of doing > Why does it need to be in QtCore?
I would put it in QtCore primarily b/c that is where QCoreApplication and QApplication live, and it should be as available to everyone as those to are. However, I am not deadset on doing so - that is part of the reason for this discussion. It could be in a QtService module. My primary concern is that it is easily available on all Qt installations as a native part of Qt. ----- Original Message ---- > From: Per Inge Mathisen <[email protected]> > On Tue, Jun 7, 2011 at 7:39 PM, BRM <[email protected]> wrote: > > A few weeks ago I proposed that QtService be integrated natively into Qt5 >[1] > > I support this and will gladly help out with as time permits. I fully > agree with the proposal except as commented below. > > > The new implementation should likely use a different name - e.g. QService, >QDaemon, or > > QDaemonService - to be more consistent with existing names of parallel > > functionality - e.g. QCoreApplication, QApplication [5] > ... > > I am going to formally propose we use QDaemonService for the name of the new > > I would suggest QServiceApplication, since it parallels the other > options (QApplication, QCoreApplication) nicely, and the word "daemon" > is a bit too tied to Unix roots. But this is probably the least > important issue :) Sounds fair, and a bit easier on the ear, no? > > QDaemonService will be a formal object like QApplication and >QCoreApplication, > > and should set up the application environment in a similar manner. That > > is, >the > > command-line options provided should be available via calling > > QCoreApplication::arguments(). It should also have a function to tell the > > program whether it is the formal service or the controller so that >developers > > can interact in both modes - thus being able to interact with the >command-line > > as necessary. > > I do not think inter-process communication by hard-wired command line > arguments was a good design. Instead, I'd rather that on Linux systemd > or upstart are used, if available, otherwise a generic dbus interface > is used; on MacOSX launchd is used; and on Windows... whatever it used > in QtService, I suppose. Then individual programmers can add control > options by command line arguments, if desired, using an API that > abstracts these interfaces and adds a means of discovery whether > another copy of the process is already running. Whether to allow > multiple instances of the service should be a programmer choice. > > I hope that made sense. Yes, I do agree that we should try to interface into various mechanisms native to the platform. On Windows that is certainly the Service API which allows control through Services.msc and other Win32 apis. It's a pain to work with, but its doable. QtService uses this now. This interface does, however, require command-line interfaces to support the interaction as that is simply how the Windows Service system expects to interact with the controller. It also provides a nice secondary alternative to having to use Services.msc - one that is sometimes quicker to access as well. I'm not familiar with Mac APIs, so I can't really comment there. I was that they do some nifty things - like only starting the service when needed to handle something. So I would really appreciate someone with Mac experience stepping up to manage that side of it to get good native support using the native APIs, and integration with launchd/etc. Linux, OTOH, is a bit more complicated. I certainly find value in having the command-line interface to control it; that is not to say that I do not also find value in having other methods. But we also have to be clear about what is being done. I think out of the gate, that we should keep the command-line interface for control but change the back-end. For example, using D-bus would be a back-end component; we might expose some stuff for an alternative control mechanism too - but it would primarily be a back-end component in which the command-line interface would certainly still be useful. I would also support enabling as an option (via Qt's configure) to support using systemd, upstart, and potentially others - but they would need to be explicitly enabled. That would give distributions the ability to integrate QServiceApplication into their mechanism of choice. Some distributions - like the Embedded Linux distro I work on - don't have systemd, upstart, etc - so the command-line is presently the only mechanism to control it. (That's not to say that won't change. That's just my only option right now - until I implement another one.) I'm sure others will be in similar situations. Further, I suggest that where it comes to the back-end communications we be as unobtrusive as possible for dependencies. That is, if Qt is configured with D-bus support then we should favor that. But if it is not then we should use another mechanism. The present one is kindof okay, but has its problems. Looking at it, it does send text data across a pipe; only to convert it to a simplistic system. It certainly could be kept as is and be very easily expanded to do other things if properly utilized. It might be a good default to keep around. So to be clear we're adding the following to the topic: 1. Integration into native service APIs where available (Windows, Mac), maintaining the command-line interface (all platforms), and adding options to use other management systems where available (Linux). 2. Modifying the back-end communication mechanism to optionally use Qt D-Bus if available, or a default mechanism if not available. At least to get going, I'd like to keep it simple. We can always add more options later. So, I'll add a goal for the initial effort of replicating what we already have under the new design. That is - using the same back-end comms and command-line interface. Once that is accomplished we can then add options to use other back-end comms and start interfacing with other service control mechanism (e.g. upstart, systemd, d-bus), and select different defaults based on the Qt Platform configuration. Thiago, As I am looking to enable both commercial licensees and FLOSS users of Qt to use this, what is the best licensing route? I noticed that the current QtService component is BSD licensed[1]. Do we need to do the same? Or is there another route we would need to take? Ben [1]https://qt.gitorious.org/qt-solutions/qt-solutions/blobs/master/qtservice/src/qtservice.h _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
