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