On Tue, 2014-05-06 at 06:58 +0200, 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.
I think what we should do is rather provide very simple example code snippets that show how to use the API from a couple of languages, and if we really think it helps maybe create a simple module that wraps these examples. It will be less time than trying to maintain C bindings for sure. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
