[Qt5-feedback] Add QtService to Qt proper

[BRM]

----- Original Message ----

> From: Thiago Macieira <thiago at kde.org>
> On Thursday, 19 de May de 2011 08:48:29 Craig.Scott at csiro.au wrote:
> > On  19/05/2011, at 4:42 AM, Thiago Macieira wrote:
> > > On Wednesday, 18 de  May de 2011 11:20:25 BRM wrote:
> > >> It could also use some TLC, for  example:
> > > Who's going to give it that TLC?
> > 
> > Well, if  Nokia shows interest in adding the QtService functionality to Qt
> > and you  ask nicely......
> > 
> > That's one of the things this list is for,  right? ;)
> 
> Nokia has no interest in adding it. The question is whether you  do, not us.
> 

I have an interest in seeing it added as I use it for 90% of my Qt-based 
applications right now. Presently I have to map in the existing QtService as a 
3rd party extension, which I then instantiate a template from, and derive from 
that to make my own service class for how my services work. As a result, I have 
to map that code in twice - once in the static library for my service class, and 
again in the main application build (I just refer to the code for the library to 
keep down the redundancy) - which is a pain to do. It's also frustrating that 
there have been no updates to it since 4.5, and while it works with 4.6 and 4.7 
it doesn't list them as supported either.

So I'd certainly be interested in being a co-developer with someone on this - 
I'm not sure my employer will go for it - especially as it is very peripheral to 
our main issues at the moment, but they'd certainly benefit; and I do have quite 
a few applications I can use as a test bed of sorts - though I can't make them 
available for all. I suspect some KDE stuff could potentially use it too - or at 
least derive from it for someone more KDE centric - the benefit being that 
background applications for KDE on Windows would be able to be full Windows 
Services as well (e.g. kded4, klauncher - don't know just a couple quick 
examples I pulled from Process Explorer). It also wouldn't be hard to make a few 
examples either.

> > QtService is presently  only supported via an add-on to Qt. I would be very 
> > helpful to have it  be part of the official Qt instead of an add-on - e.g. 
>it's 
>
> > distributed  with Qt just like QtGui.
> > It could also use some TLC, for  example:
> > 
> > - QtService is presently a set of template classes,  making use of 
>Signal/slots 
>
> > hard. It could probably be better done using  Abstract classes to define the 

> > interface.
> > - It would be useful  to schedule shutdown as opposed to having the '-t' 
>option 
>
> > simply  terminate it; probably '-t' should be "--force-shutdown" instead.
> > - The  "Interactive Service" functionality could probably be removed given 
>that 
>
> > (i) adding GUIs to services is not adviced, and (ii) Windows no longer  
>supports 
>
> > it (as of Vista). Other platforms may but we probably should  follow best 
> > practices and encourage developers to split the service  from the GUI.
> 
> 
> I very much agree with this, and given that the move to  Qt5 is going to have 
>binary compatibility breaks, it would seem to be an  opportune time to really 
>consider bringing an improved/restructured QtService  class into Qt proper. I 
>agree with Ben's view that the current templated  approach is both unnecessary 
>and a hinderance. Dispensing with the GUI support  should make for a much 
>cleaner class, and as Ben pointed out, a GUI should  really be split from the 
>service itself anyway. QtService is one of those things  that I find myself 
>asking "Why isn't this part of the main Qt libraries  already?". It makes sense 
>and fits nicely with the other set of classes provided  by Qt. I put it at a 
>similar level as QDesktopServices, QProcess and  QSharedMemory.
> 
> One of the trickier bits of using QtService at the moment  is if you want to 
>support additional command-line options beyond those defined  by QtService. This 
>is hard enough to do robustly that we basically don't want to  do it and instead 
>work around it. Maybe the command-line handling should be done  separately from 
>the QtService class and have QtService provide member functions  to do the 
>equivalent instead? FWIW, we ended up implementing our own generic  (and 
>extensible) command line argument processing class for some other work, so  we 
>have the other half of this picture. I could understand if others would be  less 
>keen to forego the bundled command-line capabilities within QtService as it  is 
>currently implemented.
> 

I would probably suggest it be in parallel to QCoreApplication/QApplication - a 
simple QService/QDaemon/QDaemonService.

I also very much agree that the command-line support needs great improvement as 
well. Though I'm not sure that can be done with the present communications 
mechanism between the controller and actual daemon - at least as it stands now. 
Not sure if continuing the 'file' controller interface is best, or whether a 
shared memory or network interface would be better - or may even a combination 
thereof (e.g. continue with the file interface for some basic commands, but then 
use another interface via network or shared memory to do more advanced things.).

Ben