On 04/25/2014 10:30 AM, Jakub Hrozek wrote:
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.
In my opinion those names are reserved for information about domains and
services, not the SSSD components. I would argue that it will not really
be used by standard users and someone capable of issuing D-Bus calls
will understand it. We use those terms in man pages anyway.
I'm not really opposed to use service instead of responder, however, I
think domain does no longer describe the backend, since you have
multiple domains per backend.