[Qt5-feedback] TLC for QtService...moving it into Qt5
andrew.stanley-jones at nokia.com
andrew.stanley-jones at nokia.com
Thu Jun 9 01:39:11 CEST 2011
While the two may live in the same module, they will have to live in parallel. SFW provides plugins and IPC across platforms between a client and service, but it places no restrictions on the service. Nor can Service Framework change names, it must maintain source compatibility.
I think it's best if QtService avoided "service" in the API or library name. Since it maybe end up in the same module as SFW it would very confusing. If it wanted to use SFW for its communications between daemons and applications, that would be logical.
-Andrew
--
Andrew Stanley-Jones, Software Engineer
Nokia, Qt Development Frameworks
Level 1, 53 Brandl St,
Brisbane Technology Park, Eight Mile Plains, QLD, Australia, 4113 http://qt.nokia.com/
-----Original Message-----
From: qt5-feedback-bounces+andrew.stanley-jones=nokia.com at qt.nokia.com [mailto:qt5-feedback-bounces+andrew.stanley-jones=nokia.com at qt.nokia.com] On Behalf Of ext BRM
Sent: Thursday, 9 June 2011 12:00 AM
To: Qt5Feedback
Subject: Re: [Qt5-feedback] TLC for QtService...moving it into Qt5
----- Original Message ----
> From: Thiago Macieira <thiago at kde.org>
> [snip]
> > 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?
>
> In order to contribute code to Qt, you need to license it under the
> Contribution License Agreement, which means your code gets released as Open
> Source under the LGPL and it allows Nokia to relicense it to Digia so they can
>
> have a commercial version.
>
> You don't need to do anything special. Just contribute the code that you write
>
> yourself. You cannot take code from somewhere else.
>
Great! That makes it easy.
----- Original Message ----
> From: "Craig.Scott at csiro.au" <Craig.Scott at csiro.au>
> On 08/06/2011, at 8:12 AM, Thiago Macieira wrote:
> > Em Tuesday, 7 de June de 2011, às 14:10:34, BRM escreveu:
> >>> 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.
> >
> > Assume that there is a place that makes it easily available to all Qt
> > installations and users. Do you need in QtCore for any special reason?
> >
> > If not, I recommend starting as an outside module. Move to QtCore if it's
> > necessary or if too many applications require it.
>
> I agree with Thiago here, and in fact I don't think you even have a choice. On
>non-Windows platforms, QtService requires QtNetwork, so the code can't be part
>of QtCore.
>
Ok. A new module it is.
The QtNetwork thing could be worked around. They just used QTcpSocket as an
interface for a pipe. It doesn't actually do networking, and QIODevice would
probably have been a bit better to derive from.
That is one of the pieces targetted to be configurable.
And, the more I think about the configuration side of things, the more sense it
makes for a new module.
----- Original Message ----
> From: "Craig.Scott at csiro.au" <Craig.Scott at csiro.au>
> On 08/06/2011, at 4:17 AM, Per Inge Mathisen wrote:
> >> 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 :)
>
> I agree, the name QServiceApplication would fit better with the proposed
>design. Personally, I'd prefer a design that let people still use a
>QCoreApplication and the service functionality was done after that, but this
>might not be so easy. If no special command-line arguments are
>needed/supported, then I'd question whether you really need to subclass
>QCoreApplication to do what is needed. If you can allow people to stick with
>using QCoreApplication, it will probably feel a bit more natural to Qt
>programmers.
>
I think it is important to use another one as there is definitely going to be
some specific functionality for the service that will need to be handled.
Current QtService does that as well, the templating just allows you to switch
between QCoreApplication and QApplication, and some other stuff.
I do agree that QCoreApplication needs to be properly interacted with so that
developers can just _use_ it.
Additionally, it should be obvious from the main function of the program that it
is a service and not a normal program - console or gui - and using a separate
class helps do just that.
> >> 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;
>
> For better portability, if possible I'd suggest avoiding relying on DBus for
>now until it makes it into the LSB. I also agree that the hard-wired command
>line arguments approach was not so great. Better to integrate with the native
>system on each platform where possible so that users don't have to learn a new
>way to control the service.
>
Agreed. As I noted in another email, I don't want to try to do this in a
well-designed configurable manner - allow people to choose to a degree what
back-end is used. By default, we should use something like what is currently
used, but design it to easily switch it out for different methods.
Same with the front-end - command-line by default, but provide options to switch
to different methods (e.g. zeroconf, systemd, upstart, launchpad, etc.).
I see these options as the second stage in the development cycle, with the first
stage just getting the basics up and working.
> > on MacOSX launchd is used; and on Windows... whatever it used
> > in QtService, I suppose.
>
> You can manage services in Windows by going to Start -> Right-click on
>"Computer" and select "Manage". From there, you can start and stop services,
>etc.
That is just another way to access services.msc.
----- Original Message ----
> From: "alex.blasche at nokia.com" <alex.blasche at nokia.com>
> >-----Original Message-----
> >From: qt5-feedback-bounces+alex.blasche=nokia.com at qt.nokia.com
> >Em Tuesday, 7 de June de 2011, às 14:10:34, BRM escreveu:
> >> > 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.
> >
> >Assume that there is a place that makes it easily available to all Qt
> >installations and users. Do you need in QtCore for any special reason?
> >
> >If not, I recommend starting as an outside module. Move to QtCore if
> >it's
> >necessary or if too many applications require it.
>
> I suggest a new module along with similar functionality. We are looking for a
>new home for the Qt ServiceFramwork in Qt and some other similar types of
>features (Qt P&S?). I couldn't come up with a good spot due to some
>dependencies and lack of a proper name for the module. I believe this would
>nicely fit together. Dependency wise this would fit together. I still don't have
>a good name for it.
>
> I would like to raise one more issue. We have a potential name clash here
>which we need to resolve. The QService* namespace is already occupied by some
>Qt SFW classes. Some aspects are similar between the two but some are
>different. The names need to distinguish them somehow.
>
This is the Qt Mobility stuff right
(http://doc.qt.nokia.com/qtmobility-1.2/classes.html - QServiceContext,
QServiceFilter, QServiceInterfaceDescriptor, QServiceManager,
QServicePluginInterface)? At least looking over that, there seems like there may
be a couple things that could be in common, but they would also need to be
drastically reworked for how services/daemons work on non-mobile platforms.
Still, it would be an interesting concept to be able to merge the two in some
way that could make for easily transitions between mobile and non-mobile
systems.
I think we need to flesh this out a bit more before it can be decided on whether
the two can integrate that way. If not, then we should probably use QDaemon* for
this work, leaving QService* available to the existing functionality - in which
case it would probably make sense to have separate modules. If they can
integrate, then I see no reason not to also use the QService* namespace and put
both in the same module.
Basically, for QtService stuff we need to:
- have something that can manage the basic daemonization
- have something that can manage a back-end communication between the service
controller and the service itself
- have something that can interact with front-end systems interfaces
(command-line, upstart, launchpad, Windows Services API, systemd, etc.)
- have an easy way for applications to integrate into the daemonization
So I think that is basically 4 primary classes (to stick with the existing
naming in this thread) - QServiceApplication, QAbstractServiceInterface,
QAbstractServiceManager, and QServiceObject respectively, with derivations for
specific interfaces for back-end and front-end systems from the two abstract
classes as appropriate for each supported mechanism - e.g.
QWindowsServiceManager, QLaunchPadServiceManager - this would replace the
service controller in QtService (front-end); QServicePipeInterface,
QServiceNetworKInterface, QServiceDbusInterface, etc - which would replace the
QTcpSocket* stuff on the non-Windows platforms in the existing QtService
(back-end).
How would this kind of functionality interact with the Qt Mobility SFW
framework? Or would they have to exist in parallel?
Ben
_______________________________________________
Qt5-feedback mailing list
Qt5-feedback at qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
More information about the Qt5-feedback
mailing list