gdbus-codegen interfaces are probably a bad idea
Submitted by Allison (desrt)
Assigned to David Zeuthen
Link to original bug (#686685)
Description
gdbus-codegen emits an interface that is implemented on both the client side (by the proxy subclass) and server side (by the skeleton subclass).
This is probably not the best thing we could do.
For method calls, in particular, it ends up being a disaster.
On the client side we have the _call_foo() wrappers that look like methods on the interface but, in reality, only work with GDBusProxy-derived classes.
On the service side, we have the handle_foo() vfuncs in the interface vtable that do not get implemented on the client side at all.
ie: for the purpose of method calls, things are completely disjoint...
For signals, things are a bit better, but not much. On the service side we have _emit_foo() functions that just emit the signal so that the default handler can call and send the signal over D-Bus. There is no real advantage here -- we could do that just as easily by emitting the signal directly from the _emit_foo() function.
Properties actually make a bit of sense...
In any case, I don't think that we gain much from having an interface shared between both sides.
We could just as easily copy the methods/properties/signals between the proxy and skeleton subclasses.
On the client side this would result in no changes to the signal/property API and would result in improvements to the method call API: we would no longer have what appears to be an interface vfunc that only works on the proxy (it would rather become a method on the proxy itself).
On the server side this would result in no changes to the signal/property API (although it would become marginally more efficient in the case of signals). For the method calls, there would be a substantial improvement: you would not need to implement the interface and could just set your handle_foo() vfuncs directly in the class structure of the skeleton.
This would also improve our ability to split out the generated code into client and server halves (a commonly-requested feature), since the two would now be completely disjoint (no longer sharing the interface)