On 05/07/2014 12:34 AM, Dmitri Pal wrote:
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@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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel