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: "[email protected]" <[email protected]> > To: [email protected]; [email protected] > 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: [email protected] >[mailto:[email protected]] 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 <[email protected]> > > [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: "[email protected]" <[email protected]> > > 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: "[email protected]" <[email protected]> > > 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: "[email protected]" <[email protected]> > > >-----Original Message----- > > >From: [email protected] > > >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 > [email protected] > http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback > _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
