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.
Of course I'm a fan of SFW staying constant, less work for me, and the current users of SFW. ;) It's already part of Qt, and has stayed source compatible since Qt Mobility. -Andrew 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). > > (?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.) > > (?c) PLATFORM-SPECIFIC REGISTRATION. Implementation properly handles > system-install/update, system-start, on-demand-start, > system-remove/uninstall, etc. > > Did I miss anything? Is this a reasonable/fair characterization? > > --charley > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest -- Andrew Stanley-Jones "It's kind of fun to do the impossible" -- Walt Disney _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
