[Development] Dynamic QtServiceFramework backend.

Corentin Jabot corentin.jabot at gmail.com
Wed May 2 13:59:02 CEST 2012


Hi.
I'm working with QtServiceFramework for remote services on Linux. It
use QDbus as a backend and it's great.

But I find more convenient to use the QLocalSocket implementation for
development and debugging purposes since it's easier to deploy and
test - the service process has it output redirected, etc.
Also it ensure a behavior exactly identical everywhere.

Currently the backend is determined when QtServiceFramwork is build,
so you have to hack the pro file to force the use of an implementation
or another.

My proposal is to compile each available backend (currently
QLocalSocket and QDBus) and add a method to QServiceManager to choose
which backend use at runtime.


bool QServiceManager::setInterProcessMethod(QService::InterProcessMethod);

enum QService::InterProcessMethod {
           Native,
           LocalSocket,
           DBus
}

The default value would be Native, corresponding on DBus where DBus is
available.

The library overhead should be minimal and this will not add
additional dependency anywhere.
It will also made easier the add of potential future implementations,
like COM on windows or things like that.

If someone think this change should be made, I'm willing to work on a patch.
Like it seems a little late for 5.0, it could be add in 5.1.


What do you think ?


Corentin Jabot,
Software Developer at Ankama, France.



More information about the Development mailing list