On 05/06/2014 11:34 AM, Sumit Bose wrote:
> On Tue, May 06, 2014 at 11:16:12AM -0400, Dmitri Pal wrote:
>> On 05/06/2014 09:34 AM, Jakub Hrozek wrote:
>>> On Tue, May 06, 2014 at 08:30:42AM -0400, Dmitri Pal wrote:
>>>> On 05/06/2014 03:52 AM, Jakub Hrozek wrote:
>>>>> On Tue, May 06, 2014 at 09:21:37AM +0200, Sumit Bose wrote:
>>>>>>> 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.
>>>>>> I agree with Stef here. Currently we have not planned bindings
>>>>>> for those
>>>>>> languages for the simple library. The intended users with the
simple
>>>>>> library are existing/legacy applications written in C which might
be
>>>>>> happier with a "classical" interface. Due to the nature
of the
>>>>>> languages
>>>>>> I would expect that applications written in Ruby, Python or Java
>>>>>> will
>>>>>> find it more easy to use the DBUS API directly.
>>>>>>
>>>>>> bye,
>>>>>> Sumit
>>>>> +1 this is what we've envisioned from the start. The bindings
>>>>> would go
>>>>> directly do the InfoPipe interface, that's also why we're
spending so
>>>>> much time on making them work as one would expect from a full DBus
>>>>> API,
>>>>> with getsetters etc. But some users (like Nikos earlier on the
>>>>> list) just
>>>>> wanted a very /simple/ get-key-value-pair API and this library can
>>>>> be it.
>>>>> _______________________________________________
>>>>> sssd-devel mailing list
>>>>> sssd-devel(a)lists.fedorahosted.org
>>>>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>>> You lost me.
>>>> Who is the consumer of the library then other than one apache module?
>>> The apache module calls DBus directly. I think the confusion comes from
>>> the fact that the apache modules call /functions/ from the DBus API
>>> that
>>> we developed while we're fleshing out the objects.
>>>
>>> Right now, Pavel would use the library and IIRC Sumit would as well.
>> For what? OpenLMI? And for...?
> libwbclient-sssd, the replacement for libwbclient which calls SSSD
> instead of winbind.
Then we can keep the library internal to SSSD for now since only SSSD
related components plan to consume it so far.
But those component won't be part of SSSD upstream so keeping it
internal will complicate things. We don't have to call it public but we
should distribute the library in a separate package and header file in
appropriate -devel package.
> bye,
> Sumit
>
>>>> Do we have a design page where it is clearly spelled out whom we are
>>>> targeting with this effort?
>>>
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusSimpleAPI
>>> _______________________________________________
>>> sssd-devel mailing list
>>> sssd-devel(a)lists.fedorahosted.org
>>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>>
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager IdM portfolio
>> Red Hat, Inc.
>>
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel(a)lists.fedorahosted.org
>>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel