On Mon, May 05, 2014 at 05:08:39PM +0200, Pavel Březina wrote:
On 05/05/2014 02:06 PM, Stef Walter wrote:
On 01.05.2014 17:39, Pavel Březina wrote:
https://fedorahosted.org/sssd/ticket/2254
Lukáš already did first round of review for build and packaging stuff. Thank you, I hope I have fixed all your concerns. There might be some more since I moved the library into libsss_dbus and libsss_dbus-devel packages.
The library is built if IFP responder is built.
As noted on IRC, I don't think this should be a public sssd API. As internal code of the OpenLMI IFP provider it makes sense.
But remember the public API *is* DBus itself. Callers of the sssd DBus API should use their local DBus facility in their language or toolkit to talk with sssd (ie: GDBus or python-dbus, or what have you).
I realize that sssd at present has no such local DBus facility in its toolkit (libdbus doesn't count, it's too low level) and that having such a client library internal to sssd makes sense. If it could be based on the codegen work that would be even better.
But, back to the point: I would caution against making it a public API and having it become an fixture that people turn to when trying to talk with SSSD.
Do we want the InfoPipe provider to be used at all? Sure, big projects and skilled developers can stick with gdbus but why every single project should write the same hundreds lines of code to do the most common tasks? I think having such library will make using the InfoPipe a less pain.
Of course, this library does not completely hide the D-Bus for method calls, it is a compromise between universality and the need to completely reflect our D-Bus interface in this library. However, it still hides D-Bus completely when dealing with properties.
I want to keep the OpenLMI provider clean and bring as many things on SSSD side as possible. This library allows me to do it.
Sure, we don't have to make it a public API, even though it was the original intention. I can make it an OpenLMI client or put it completely into the OpenLMI provider tree.
Also some developers were a bit nervous when we proposed that they need to interact with DBus directly at the C level or were outright rejecting talking to the system bus directly.
It's a bit of Pandora box, though, we'd need to be very strict about this new interface in case somebody comes with an RFE..the DBus interface is /the/ interface...