[Development] Qt Playground - Updating Daemon/Service Support

Charley Bay charleyb123 at gmail.com
Mon Nov 26 20:26:11 CET 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121126/3c65f6bb/attachment.html>


More information about the Development mailing list