On 14 Feb 2018, at 20:55, Jakub Hrozek <jhrozek(a)redhat.com>
wrote:
On Sat, Feb 03, 2018 at 12:58:26PM +0100, Pavel Březina wrote:
> Hi team,
> as you know, I have been working on this occasionally for a long time now.
> The code can be found at [1].
>
> It is completely new implementation of our internal D-Bus API called sbus. I
> took all the good things started by Steff Walter few years ago and made them
> better and more flexible. In short, it is everything you ever wanted and you
> will not use D-Bus with it at all.
>
> There is a large README.md in the repo, that contains complete list of
> features, explanation why I started working on this and what I wanted to
> achieve. There is also shorter list of some chosen benefits to the SSSD
> project so you can get the general idea without going through the all
> feature list.
>
> I really believe that this will be a big step forward for SSSD project as it
> will make the code much simpler and testable and it will allow us to extend
> our D-Bus interface both external and internal. It will give us the
> opportunity to improve the InfoPipe responder (and finally allow us to
> implement write interface) but it also allows us to improve the
> communications between providers, responders and even tools -- especially
> sssctl.
>
> There is also a showcase application so you can see most of the features at
> work. All is described in the readme file.
>
> It lacks unit tests at the moment. I would like to get some help from you in
> this area, we should talk about it in the meeting or here. If we choose to
> integrate this with our codebase, we should talk about schedule and test
> plan.
>
> Also, I would like to strip it from SSSD's dependencies eventually and
> release it as a public library. But that will not happen in near future.
>
> I hope you will like it.
I didn't have the time to read the implementation at all, honestly, I only
read the README.md. But I like the ideas, especially that we could finally
get support for signals and that the processes could communicate with one
another more easily.
OK, now I had time to look at the code. It’s a lot to digest, but what I saw so far I
like.
For anyone who is following this list, but didn’t look at the code, the reason I think we
want this code is:
- we want to make it easier for different SSSD processes to talk to one another. Think
KCM<->IFP for notifications, sending signals if sssd_be reconencts to a different
server etc
- all the requests are tevent requests with C data types
- we get a nice access control handler per method.
So I'm all for merging this. But I'm sure when will I have
the time to
review the code -- currently I'm busy looking at PRs for your other
project :-)
btw with my maintainer hat on -- I think changes like this would really
require us to split master from sssd-2.0.
I still think this is the case. We spent some time on the phone with Pavel this week and
agreed that Pavel would submit this work for SSSD. But the changes are quite big and I
don’t want to merge such radical change into the sssd-1-16 branch.