[Development] Qt Playground - Updating Daemon/Service Support

[Matt Broadstone]

On Mon, Nov 26, 2012 at 1:48 PM, BRM <bm_witness at yahoo.com> wrote:

> > From: Charley Bay <charleyb123 at gmail.com>
>
> >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).
> >
>
>
> Note: Only the use of the QtService /QService name would have such
> collision. That is why the new API would be DaemonApplication
> (QDaemonApplication), as discussed previously on the mailing lists.
>
> Ben
>

thoughts:

a) I think the only reason the old QtService uses a template based approach
is to support the different types of Q*Application. It would be quite
useful to have someone who worked on the original solution discuss why they
went with this approach rather than subclassing Q*Application. I imagine
with a subclass approach you would solve a lot of your "cleanup" problems
as well.

b) Not sure what you guys are talking about with IPC/QLocalSocket, this
seems beyond the scope of these classes

c) I believe Service was used originally because it corresponds to the
windows world-view of daemons/services (it also explains why the class
itself seems to be more of a fair player on windows rather than *nix). The
renaming is fine, but I guess you are committing the reverse sin here.

d) at this point talk is cheap, show me the code! :)

Is there any word on whether you guys get a spot in playground?

Matt



> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121126/f4ee64ac/attachment.html>