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

[Jason H]

Can you make it support zeroconfig/bonjour too?
libQxt already has some zero config code under LGPL. I don't know if you want to use that directly or write your own.





________________________________
From: BRM <bm_witness at yahoo.com>
To: Qt5Feedback <qt5-feedback at qt.nokia.com>
Sent: Tuesday, June 7, 2011 1:39 PM
Subject: [Qt5-feedback] TLC for QtService...moving it into Qt5

A few weeks ago I proposed that QtService be integrated natively into Qt5 [1], 
and I offered to spearhead that task [6] and support Windows and Linux (Embedded 
and X11)[6].
End of last week I setup a branch of the Qt5 master repository[10] for 
supporting this task, and am working to get up to speed on using git (I have 
primarily used SVN), so I expect that getting going will be a little slow in 
that respect.

All that said, I am looking for anyone else that wants to help out (I've already 
received one offer), and I'd like to open up a thread on the design/naming/etc. 
for what will be going on.
If people prefer, I'll be happy to take that discussion to a dedicated list, but 
at least initially [7] it's been suggested to keep it here.

With that, I've summarized the previous posts below:

QtService is presently an add-on provided by Trolltech/Nokia through the Qt 
Components system [1]. However, for a variety of reasons it is desirable by 
myself and others that it be a native part of Qt [1,3] whether as part of Qt 
Core or a module provided with Qt itself [1, 9]. In either case, it needs some 
TLC to bring it up to date as well as some improvements. To start, the existing 
QtService implementation is a C++ Template-based implementation[1,3]; the end 
result is that this prohibits use of signals/slots internally to the QtService 
code [1,3], prevents the ability to do a scheduled, orderly shutdown [1], and 
makes it hard to work with the command-line [3,5].

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 so the 
ability to derive an interactive service will be removed per encouraging best 
practices and that it will not work on all platforms [1, 3]. 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], and should address 
issues in the command-line [3,5], communication between controller and service 
[5], and add the ability to do controller shutdowns of the service [1].

(end summary)

Naming:

I am going to formally propose we use QDaemonService for the name of the new 
class (which I will use for the duration of this email). Reasoning: Per previous 
statements [5] it fits with the naming convention of parallel functionality - 
QCoreApplication, QApplication, and it also should help keep mental barriers 
intact as Unix people are use to calling such things 'daemons' and Windows 
people are use to calling them 'services'. (I often have to call it a Deamon 
Service myself to get that point across.) So it utilizes both conventions and 
makes it clear what it is.

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.

QDaemonService will function simiarly to QApplication and QCoreApplication in 
instantiating the program. For example, the basic program would be:

#include <QDeamonService>

int main(int argc, char* argv[]) {
    QDaemonService service(argc,argv);
    ...

    return service.exec();

}


Developers will be required to derive the main object from a new specialized 
QObject derivative - e.g. QDaemonServiceObject - that can take care of 
initializing and connecting to the environment much like QObject and QWidget do 
for QCoreApplication and QApplication programs respectively. The new derivative 
object can set up communication between the controller and daemonized service 
using signals/slots, and provide some key interfaces that developers can use for 
various points - e.g. pre-daemoinization command-line interaction, 
post-daemonizing start/pause/resume/scheduled stop/halt stop operations.
I think that's enough to get some discussion going.

Thoughts?

Ben


[1] http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/000246.html
[2] http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/000247.html
[3] http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/000253.html
[4] http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/000256.html
[5] http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/000259.html
[6] http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/000262.html
[7] http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/000266.html
[8] http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/000267.html
[9] http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-May/000264.html
[10] https://gitorious.org/~benjamenmeyer/qt/brm-qt5-service
_______________________________________________
Qt5-feedback mailing list
Qt5-feedback at qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20110607/fc98ba5a/attachment-0001.html