[SSSD] [PATCH] libsss_dbus

Dmitri Pal dpal at redhat.com
Mon May 5 23:51:29 UTC 2014


On 05/05/2014 12:28 PM, Pavel Březina wrote:
> On 05/05/2014 06:17 PM, Sumit Bose wrote:
>> On Mon, May 05, 2014 at 05:38:58PM +0200, Pavel Březina wrote:
>>> On 05/05/2014 05:25 PM, Jakub Hrozek wrote:
>>>> 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...
>>>
>>> I can amend the documentation to make it more clear.
>>
>> The idea was that this library just provide some lookup calls for common
>> stuff like list of trusted domains and some user attributes which goes
>> beyond the POSIX interface on top of the D-BUS API to facilitates
>> adoption. It's a convenience library and there is no plan to wrap the
>> whole D-BUS API in this library.
>
> Yep, that's not what it's doing.

Yes the intent was to make it public so that it can be easily called 
from a python, ruby or java app to get missing data when an admin is 
defining roles in the context of the application.
So please make it targeted and public. There will be consumers of this 
API quite soon: Foreman, oVirt, Keystone and others...
>
>> bye,
>> Sumit
>>
>>>
>>> _______________________________________________
>>> sssd-devel mailing list
>>> sssd-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.




More information about the sssd-devel mailing list