> From: Charley Bay <charleyb...@gmail.com> >Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support > > >Hi, Matt-- > > >thoughts: >> >> >>a) I think the only reason the old QtService uses a template based approach >>is to support the different types of Q*Application. It would be quite useful >>to have someone who worked on the original solution discuss why they went >>with this approach rather than subclassing Q*Application. I imagine with a >>subclass approach you would solve a lot of your "cleanup" problems as well. > > >Agreed. However, I think BRM's thought is that you just instantiate your >instance, and then (separately) instantiate the "QGuiApplication" or >"QCoreApplication" (e.g,. the "SomeNewService" instance does not need to be a >template at all). >
At one point in time it was okay to have a QApplication/QGuiApplication as a daemon. However, as of Windows Vista, and more greatly enforced in later versions of Windows, Microsoft is severely curtailing the abilities of Services to have a GUI interface. As such it is really only valid on Windows to have a QCoreApplication-based Service/Daemon. I don't think most *nix applications typically put a GUI on a daemon, so they probably don't run into that issue. So, I would say that the need for a QGuiApplication/QApplication based service is no longer. Developers should instead use a Client-server model approach to provide a GUI application with a service back-end, using the communication protocol/method of their choice. >b) Not sure what you guys are talking about with IPC/QLocalSocket, this seems >beyond the scope of these classes >All services/daemons must be able to interface with other processes: > (a)- a "client-process" can "request-a-client-operation" to occur on that >service/daemon > (b)- a process can "query" or "control" the service/daemon (such as to >"pause" it, or "stop" it, etc.) >Thus, some inter-process communication is always required. Correct. There are two sides to the application - the controller which the user interacts with, and the service/daemon which runs without any real interface. IPC is required, and it should be relegated to local system communications only for security purposes. QtService<> uses a named pipe on *nix and only transfers Strings across. While we'll probably only transfer strings, I'd like to leave the option to transfer other data as well, and I think QLocalSocket is probably a better option than doing what QtService<> did in writing their own wrappers around various methods to produce a similar API for their own use. Why reinvent a part of Qt that already solves the problem? >c) I believe Service was used originally because it corresponds to the windows >world-view of daemons/services (it also explains why the class itself seems to >be more of a fair player on windows rather than *nix). The renaming is fine, >but I guess you are committing the reverse sin here. >Agreed -- "Service" is understood on "Windows", and "Daemon" is understood on >"*nix". I don't really care about the name -- there is merely a need to >disambiguate whatever it is with the things in the "Qt Service Framework". > Agreed. And as noted this was discussed at length in the original e-mails back in the qt5-feedback days. I had proposed using QServiceApplication figuring that would be a nice follow on to QtService and more native, or QDaemonServiceApplication to bridge the gap for both. And I honestly don't really care except I'd like to keep the Q*Application name to show that it is in parallel to QCoreApplication/QApplication/QGuiApplication, so that people don't try to create both the daemon-service class and the other in the same application. >d) at this point talk is cheap, show me the code! :) >Is there any word on whether you guys get a spot in playground? > >That's why the "playground" was requested. ;-)) > I have an initial draft I am working on at home. I'll put it in the playground project if created once I have access to do so. Ben _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
