[SSSD] Design Discussion: D-Bus responder

Jakub Hrozek jhrozek at redhat.com
Fri Apr 25 08:30:05 UTC 2014


On Thu, Apr 24, 2014 at 10:38:33AM +0200, Pavel Březina wrote:
> Hi,
> I made some more changes, please review.
> 
> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
> 
> The way I see SSSD terminology:
> responder is a process providing particular service
> backend is a process managing one or more domains
> 
> We were combining abilities (debug level, enabled/disabled) of sssd
> processes (responders, backends) with logical units (services,
> domains). I think this wasn't very clear approach. There was at
> least one big problem, that I struggled with:
> 
> Only root SSSD domain have these properties, they don't apply to
> subdomains. We could either split subdomains to separate object type
> or inherit this property from parent domain. But I found it very
> confusing when you start changing this properties.
> 
> I defined a separate objects under infopipe/Components tree that
> implements infopipe.Components interface. This way it is completely
> separated from services and domains, which can focuses purely on
> their properties and methods.

The logical split and the proposed methods looks good to me.

My only concern is that "backend" and "responder" are too developer-centric
name. I think that 'Domain' and 'Service' are better understood by
non-developers because that's how we name things in the config file.



More information about the sssd-devel mailing list