On Mon, Nov 26, 2012 at 10:40 AM, Matt Broadstone <mbroa...@gmail.com>wrote:
> On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay <charleyb...@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
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development