[Development] Qt Playground - Updating Daemon/Service Support

[Charley Bay]

On Mon, Nov 26, 2012 at 10:40 AM, Matt Broadstone <mbroadst at gmail.com>wrote:

> On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay <charleyb123 at gmail.com>wrote:
>
>> >>> <snip, updating the "QtService<>" Component >,
>> >>> I would like to open a new Qt Playground project to create a new
>> equivalent
>>
>> +1
>>
>> IMHO this would be a cross-platform useful module that I'd vote to
>> ultimately end-up within "Qt-proper".
>>
>> Disclosure:  I traded emails with BRM off-list, and would like to help.
>>
>> --charley
>>
>
> Would you guys like to get into your design a little here? Did you mean
> that you would be creating two classes: QCoreService/QGuiService (though
> I'm not sure why one would want a gui service, maybe to use some of the
> graphics classes?). Also, could you speak to your ideas for the pluggable
> backend? Will you target systemd as a reference implementation?
>
> Matt
>

[UPDATE], I was typing this while BRM responded.  Read his email, it's a
more specific "design-ideas" answer.  However, I'll still reply with this
email, since it talks about other "higher-level" issues-to-be-resolved, and
brings the discussion "current" with what this proposed-playground is to do.

[...what follows is what I was typing when BRM responded...]

I'm "second-seat" (Ben/BRM is taking the lead).  I defer to Ben/BRM for any
corrections needed from malicious dis-information created as a result of
this email, but here's a bullet-list of early thoughts:

TODAY:

 (a)- The existing "QtService<>" is an add-on (not in "Qt-proper"), but
people use it, and it serves a purpose to help provide a cross-platform
"service/daemon" application API.

 (b)- The existing "QtService<>" works for Qt4x (likely "needs-work" to
support Qt5)

GOAL:

After this effort, the result could be considered as a Qt5+ "add-on" for
cross-platform service/daemon support, and possibly considered for
inclusion in a future Qt release (e.g., perhaps Qt5.1+)

POSSIBLE ISSUE:

An "unfortunate" name collision (or user-confusion) is possible with class
names created from this effort to provide a cross-platform service/daemon
API, and those classes within the "Qt Service Framework" (which has a
different purpose).

USE GOAL:

Very simple API to create a service/daemon (server-side), or client-process
instance (client-side), such as merely "instantiating" an object.  Current
thoughts are to make this similar to merely instantiating a
"QCoreApplication" or "QGuiApplication".  (For example, the user may merely
instantiate  from within "main()" a "service-application-instance" or
"client-to-service-application-instance").  (SEE BRM's EMAIL FOR MORE
DETAIL.)

CURRENT DESIGN THOUGHTS:

Speculative design is to:

 (a)- Make "QtService<>" (currently a "template<>") a non-template (e.g.,
"directly-instantiable")

 (b)- Improve "shut-down" semantics (e.g., current "QtService<>" just does
a "hard-kill" on the server process, so no waiting/clean-up is performed,
including within threads; this should handle a graceful resource clean-up)

 (c)- Improve "robustness" (e.g, better use of waits/resource clean-up; the
current "QtService<>" works, but can leave applications "broken" at times)

 (d)- Implementation likely enforces a "local-to-the-same-computer"
client/server inter-process communication (e.g., using something like
"QLocalSocket")  (Might consider future expansion of
non-local-to-the-same-computer).

 (e)- Platform-specific registration (e.g., properly handle
systeminstall/update, system-start, on-demand-start,
system-remove/uninstall, etc.)  Would "by-default" support a command-line
interface, and maintain compatibility between client/server process.
 Further development could add other interfaces (e.g., "systemd") to
integrate with other systems more easily.

FWIW.

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121126/bf7bf733/attachment.html>