[Development] Qt Playground - Updating Daemon/Service Support

[BRM]

> From: Charley Bay <charleyb123 at 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