[SSSD] [PATCH] libsss_dbus

Pavel Březina pbrezina at redhat.com
Tue May 6 07:06:46 UTC 2014


On 05/06/2014 06:58 AM, Stef Walter wrote:
> On 06.05.2014 01:51, Dmitri Pal wrote:
>> 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.
>
> Then at a very minimum we should call this library
> "libsimpleifpclient.so" or something like that... Calling it
> libsssd_dbus.so is really confusing.
>
>>> 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...
>
> This is backwards.
>
> It's easy to call DBus from python, java and friends. There's no need to
> pass that interaction through the bottleneck (albeit simple bottleneck)
> that this library provides. At the current time this library is not
> thread-safe, not loop-integratable, not-abi-extensible etc. It would
> need to look significantly different to provide the foundation for what
> you provide there. And why? The callers you suggest already have solid
> ways to call DBus. It's sssd/tevent that doesn't.

It is thread safe as long as you use separate context for each thread.

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