[Qt5-feedback] TLC for QtService...moving it into Qt5
BRM
bm_witness at yahoo.com
Thu Jun 9 22:11:29 CEST 2011
Agreed.
Ok. I think we've gotten quite a bit fleshed out here. I think it's time to
(again) summarize the discussion, but this time I'd like to place it on a Wiki
for review and comment to make sure we're all on the same page.
Is the Wiki for the http://developer.qt.nokia.com/forums the best place to do
this? Or is there some place better?
If need be, I'll use my own blog (and post a link here), but I'd rather use an
editable Wiki.
Thanks,
Ben
----- Original Message ----
> From: "andrew.stanley-jones at nokia.com" <andrew.stanley-jones at nokia.com>
> To: bm_witness at yahoo.com; qt5-feedback at qt.nokia.com
> Sent: Wed, June 8, 2011 7:39:11 PM
> Subject: RE: [Qt5-feedback] TLC for QtService...moving it into Qt5
>
> 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