On 08/06/2011, at 4:17 AM, Per Inge Mathisen wrote: > >> 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 :)
I agree, the name QServiceApplication would fit better with the proposed design. Personally, I'd prefer a design that let people still use a QCoreApplication and the service functionality was done after that, but this might not be so easy. If no special command-line arguments are needed/supported, then I'd question whether you really need to subclass QCoreApplication to do what is needed. If you can allow people to stick with using QCoreApplication, it will probably feel a bit more natural to Qt programmers. >> 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; For better portability, if possible I'd suggest avoiding relying on DBus for now until it makes it into the LSB. I also agree that the hard-wired command line arguments approach was not so great. Better to integrate with the native system on each platform where possible so that users don't have to learn a new way to control the service. > on MacOSX launchd is used; and on Windows... whatever it used > in QtService, I suppose. You can manage services in Windows by going to Start -> Right-click on "Computer" and select "Manage". From there, you can start and stop services, etc. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
