[Qt5-feedback] TLC for QtService...moving it into Qt5

[BRM]

----- Original Message ----
> From: Thiago Macieira <thiago at kde.org>
> Em Tuesday, 7 de June de 2011, às 10:39:15, BRM escreveu:
> > It has been  proposed to make a new QtService implementation that makes use
> > of   C++ Abstract Interface classes instead [1,3]. In the process of doing
> Why  does it need to be in QtCore?

I would put it in QtCore primarily b/c that is where QCoreApplication and 
QApplication live, and it should be as available to everyone as those to are.
However, I am not deadset on doing so - that is part of the reason for this 
discussion. It could be in a QtService module.
My primary concern is that it is easily available on all Qt installations as a 
native part of Qt.


----- Original Message ----
> From: Per Inge Mathisen <per.mathisen at gmail.com>
> On Tue, Jun 7, 2011 at 7:39 PM, BRM <bm_witness at yahoo.com> wrote:
> > A  few weeks ago I proposed that QtService be integrated natively into Qt5  
>[1]
> 
> I support this and will gladly help out with as time permits. I  fully
> agree with the proposal except as commented below.
> 
> > The new  implementation should likely use a different name - e.g. QService, 
>QDaemon,  or
> > QDaemonService - to be more consistent with existing names of  parallel
> > functionality - e.g. QCoreApplication, QApplication  [5]
> ...
> > I am going to formally propose we use QDaemonService for the  name of the 
new
> 
> I would suggest QServiceApplication, since it parallels  the other
> options (QApplication, QCoreApplication) nicely, and the word  "daemon"
> is a bit too tied to Unix roots. But this is probably the  least
> important issue :)

Sounds fair, and a bit easier on the ear, no?
 
> > QDaemonService will be a formal object  like QApplication and 
>QCoreApplication,
> > and should set up the  application environment in a similar manner. That is, 
>the
> > command-line  options provided should be available via calling
> >  QCoreApplication::arguments(). It should also have a function to tell  the
> > program whether it is the formal service or the controller so that  
>developers
> > can interact in both modes - thus being able to interact with  the 
>command-line
> > as necessary.
> 
> I do not think inter-process  communication by hard-wired command line
> arguments was a good design.  Instead, I'd rather that on Linux systemd
> or upstart are used, if available,  otherwise a generic dbus interface
> is used; on MacOSX launchd is used; and on  Windows... whatever it used
> in QtService, I suppose. Then individual  programmers can add control
> options by command line arguments, if desired,  using an API that
> abstracts these interfaces and adds a means of discovery  whether
> another copy of the process is already running. Whether to  allow
> multiple instances of the service should be a programmer  choice.
> 
> I hope that made sense.

Yes, I do agree that we should try to interface into various mechanisms native 
to the platform.

On Windows that is certainly the Service API which allows control through 
Services.msc and other Win32 apis. It's a pain to work with, but its doable. 
QtService uses this now. This interface does, however, require command-line 
interfaces to support the interaction as that is simply how the Windows Service 
system expects to interact with the controller. It also provides a nice 
secondary alternative to having to use Services.msc - one that is sometimes 
quicker to access as well.

I'm not familiar with Mac APIs, so I can't really comment there. I was that they 
do some nifty things - like only starting the service when needed to handle 
something. So I would really appreciate someone with Mac experience stepping up 
to manage that side of it to get good native support using the native APIs, and 
integration with launchd/etc.

Linux, OTOH, is a bit more complicated. I certainly find value in having the 
command-line interface to control it; that is not to say that I do not also find 
value in having other methods. But we also have to be clear about what is being 
done. I think out of the gate, that we should keep the command-line interface 
for control but change the back-end. For example, using D-bus would be a 
back-end component; we might expose some stuff for an alternative control 
mechanism too - but it would primarily be a back-end component in which the 
command-line interface would certainly still be useful. I would also support 
enabling as an option (via Qt's configure) to support using systemd, upstart, 
and potentially others - but they would need to be explicitly enabled. That 
would give distributions the ability to integrate QServiceApplication into their 
mechanism of choice.  Some distributions - like the Embedded Linux distro I work 
on - don't have systemd, upstart, etc - so the command-line is presently the 
only mechanism to control it. (That's not to say that won't change. That's just 
my only option right now - until I implement another one.) I'm sure others will 
be in similar situations.

Further, I suggest that where it comes to the back-end communications we be as 
unobtrusive as possible for dependencies. That is, if Qt is configured with 
D-bus support then we should favor that. But if it is not then we should use 
another mechanism. The present one is kindof okay, but has its problems. Looking 
at it, it does send text data across a pipe; only to convert it to a simplistic 
system. It certainly could be kept as is and be very easily expanded to do other 
things if properly utilized. It might be a good default to keep around.

So to be clear we're adding the following to the topic:

1. Integration into native service APIs where available (Windows, Mac), 
maintaining the command-line interface (all platforms), and adding options to 
use other management systems where available (Linux).
2. Modifying the back-end communication mechanism to optionally use Qt D-Bus if 
available, or a default mechanism if not available.

At least to get going, I'd like to keep it simple. We can always add more 
options later.

So, I'll add a goal for the initial effort of replicating what we already have 
under the new design. That is - using the same back-end comms and command-line 
interface. Once that is accomplished we can then add options to use other 
back-end comms and start interfacing with other service control mechanism (e.g. 
upstart, systemd, d-bus), and select different defaults based on the Qt Platform 
configuration.

Thiago,

As I am looking to enable both commercial licensees and FLOSS users of Qt to use 
this, what is the best licensing route? I noticed that the current QtService 
component is BSD licensed[1]. Do we need to do the same? Or is there another 
route we would need to take?

Ben

[1]https://qt.gitorious.org/qt-solutions/qt-solutions/blobs/master/qtservice/src/qtservice.h