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.
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

Reply via email to