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.
The memory allocation routines are not thread-safe. It seems this
library is to be used in "plugin" environments (openlmi providers,
apache modules ...) and in those cases providing global memory
allocation overrides are prone to races (both of the threading variety
and otherwise).
Cheers,
Stef