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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel