----- 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
