[SSSD] [PATCH] libsss_dbus

Pavel Březina pbrezina at redhat.com
Mon May 5 16:28:14 UTC 2014


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.

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




More information about the sssd-devel mailing list