> From: Andrew Stanley-Jones <a...@cban.com> >Subject: Re: [Interest] Qt5: Status of, "Add QtService to Qt proper" >Hey Guys, > >Before this ends up in Qt5 we have to deal with the name conflict. >QtService way to easily confused with Qt Service Framework. There's >already a suggested rename of SFW to Qt Service since everything in Qt >is a framework. But in either case, renames are costly for everyone >involved.
The naming conflict was part of the discussion prior. IIRC, it wasn't quite decided but I was leaning towards QDaemonApplication. >On Tue, Nov 20, 2012 at 4:14 AM, Charley Bay <charleyb...@gmail.com> wrote: >>>> Last June there was a thread with the title, "Add QtService to Qt >>>> proper" that discussed some tender-loving-care required to update >>>> "QtService<>" to support Qt5. >>>> >>>> RECALL that "QtService<>" is a template add-on (not in >>>> Qt-proper) that >>>> targeted Qt4, and talk was to make it a non-template, and to add it to >>>> Qt5-proper, probably in the "network" module. >>>> >>>> Original thread starts here: >>>> >>>> <http://lists.qt.nokia.com/pipermail/qt5-feedback/2011-June/000449.html> >>>> >>>> Some other feedback discussion here: >>>> >>>> <http://comments.gmane.org/gmane.comp.lib.qt.qt5-feedback/76> >>>> >>>> QUESTION: Where did this end-up in Qt5? >> >> Ben respondeth: >>> Simply put, I haven't had time to work on it. >>> >>>> If someone wanted a "QtService<>"-type thing (service/daemon) in >>>> Qt5, what would be the recommended approach? >>> >>> I don't know if the original QtService<> Component would work with Qt5; >>> however, I'd love to work with you and anyone else that wants to do what I >>> originally proposed with an adjusted target - perhaps 5.1. >> >> I might be able to help with that. There's enough discussion on the >> web about the value of a "QtService" thing (and its companion >> classes), that: >> >> (1) It has cross-platform value for many users >> >> (2) I think it should end up in Qt "proper" >> >> (3) I think your previous thoughts on this (and the in-depth >> discussion on the email list) was well-thought-out. >> >> For the casual reader, Ben has a couple blog entries on this topic, >> the latest one that I can find (which references a previous one) is >> at: >> >> <http://clocksmind.blogspot.com/2011/09/qt5-introducing-qdaemonapplication.html> >> >> Just so I understand, at a HIGH LEVEL, is the scope intended to be: >> >> (?a) EASY TO USE. Provide an easy-to-use API (like QApplication or >> QCoreApplication) that implements a "service/daemon" in a >> cross-platform way (e.g., Win/*nix/etc). This implies a "blocking" >> execution while the service runs (e.g., it's a service/daemon). Yes, I'd really like the user (e.g. developer) to be able to create a service using the following: int main(int argc, char* argv[]) { QDaemonApplication theService(argc, argv); myApplication theApplication; return theService.exec(); } Or at least something very similar to it. One of the main goals is to not make it be a template class like QService is now; as well as enable the service to properly shutdown. QService presently just does a hard kill on the service process when it gets the terminate option on the command-line, so the service application has no means of waiting for anything to clean up (threads included). It works, but the end result can leave applications broken at times very easily. >> (?b) SIMPLE/STANDARD INTER-PROCESS COMMUNICATION. Clients can access >> the service/daemon in a simple-and-standard-way (e.g., >> reading-and-writing text to ports, etc.) I've been on the Developer's list for a while, as well as this list. In observing the discussions over the many months, I started to think about using QLocalSocket - at least out of the gate - to do the IPC between the daemon-service and user controller, at least for *nix. They typically need to be on the same computer, so it seems like a good option to enforce that. >> (?c) PLATFORM-SPECIFIC REGISTRATION. Implementation properly handles >> system-install/update, system-start, on-demand-start, >> system-remove/uninstall, etc. Correct. Initial out-of-the-gate would re-implement the same existing command-line interface in order to get it up and going, and maintain compatibility. Further development would add other interfaces - e.g. systemd - to integrate into other systems more easily. >> Did I miss anything? Is this a reasonable/fair characterization? I think you got it as far as what I had blogged and what was discussed on the mailing list. In what little time I did get towards trying to implement it, I had mostly been trying to think about the interface for enabling the application to manage the command-line so that a more extensive command-line could be utilized, both before and after the daemonization occurred - before so that QDaemonApplication or the main application could process the command line and decide it didn't need to run, and after so that the application could get any command-line options it needed during run-time. One main hang-up for me at the time was getting Qt5 compiling. Ben _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
