[SSSD] [PATCH] libsss_dbus

Jakub Hrozek jhrozek at redhat.com
Mon May 5 15:25:56 UTC 2014


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...



More information about the sssd-devel mailing list