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.
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.