Closed sgallagher closed 8 years ago
First results: gdbus: There is a big issue with not being able to create a server that is really doing something useful with the python bindings: The virtual table for handling properties and method calls for a D-Bus interface is not usable since a long time: https://bugzilla.gnome.org/show_bug.cgi?id=656325
PyQt: There is no support for the dbus standard types with the PyQt dbus bindings. It is needed to create and also register types. For example it is not possible since PyQt5 to have a list of strings in a simple way, because with the PyQt5 bindings there is no QStringList anymore.
We discussed this at the rolekit meeting yesterday. We've decided to proceed with the gdbus option. Thankfully, the virtual table bug was actually resolved yesterday, so that impediment to migration is now out of the way.
A conversion of rolekit to another dbus implementation might not be needed. It is possible to provide the Introspect method in the introspectable interface where properties are added by the objects.
These are the results of the POC implementations:
A transition to another dbus implementation might not be the best solution for now as there will most likely be the need to migrate to sd-bus at some point in the nearer future, if kdbus made it into the upstream kernel and is used by default. sd-bus could be the only dbus implementation that is providing all features of kdbus. It is questionably if there will be a complete implementation for other dbus backends.
By providing a custom Introspect method, the needed code changes are small using python-dbus. This has been revealed by lvm-dubstep: https://github.com/tasleson/lvm-dubstep
Rolekit is depending on some functionality in the Fedora version of the python-dbus package that upstream does not want to support.
We should investigate switching to either gdbus through python-glib or qtdbus through PyQt5.