[Interest] Qt5: Status of, "Add QtService to Qt proper"

[Andrew Stanley-Jones]

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