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.