On Wed, Jan 28, 2015 at 02:00:59PM -0500, Pavel Brezina wrote:
----- Original Message -----
> From: "Jakub Hrozek" <jhrozek(a)redhat.com>
> To: sssd-devel(a)lists.fedorahosted.org
> Sent: Wednesday, January 28, 2015 12:22:09 PM
> Subject: Re: [SSSD] Design Discussion: Domains, users and groups over D-Bus
> On Wed, Jan 28, 2015 at 10:28:34AM +0100, Pavel Březina wrote:
> > On 01/14/2015 04:19 PM, Pavel Březina wrote:
> > >On 01/12/2015 03:51 PM, Pavel Březina wrote:
> > >>On 12/16/2014 02:26 PM, Pavel Březina wrote:
> > >>>https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
> > >>
> > >>I created a new design page to reduce size and increase readability in
> > >>the original one. I would like to keep DBusResponder page mainly as a
> > >>crossroad with links to other pages in the future so it is not swamped
> > >>with too many details on everything.
> > >>
> > >>I will replace user and group design in DBusResponder with the
> > >>link if you agree:
> > >>
> > >>https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
> > >>
> > >>It should cover everything we agreed on. If not, please tell me and I
> > >>will add it.
> > >
> > >New iteration is available at:
> > >https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
> > I think we should rethink the object paths. Currently it contains only $UID
> > information which should be unique across all domain. Therefore we relay on
> > sysdb_getpwuid, however, this function still requires domain.
> > We can either iterate over all domains and use the first match, or we can
> > add domain information into the object path:
> > /ifp/Users/$domain/$uid
> Is it about the object path only?
> From application perspective, the UID might be the only input data they have
> (think file ownership), we should provide a mean to retrieve a user
> based on this data only. The fact that we use 'domains' is not
> interesting for applications.
Yes, it is only about the domain path. The object path can be obtained by uid
search with Users.FindByID(id), not domain is required there.
We can iterate through all the domains in the getters, but having the domain as a part of
an object path is simply more convenient.
> I don't have a problem with adding domain to the path, after all, the
> user is not supposed to construct the paths himself, he ought to use the
> Find() methods. But I think we shouldn't require the domain to be an
> input parameter.
I'm also thinking about more complex and more object oriented interface usage.
ifp.Users.ListByName on /ifp/Users
ifp.Users.ListByName on /ifp/$domain/Users
The later can replace ListByDomainAndName(domain, filter, limit) method.
User object path can then look like: /ifp/$domain/Users/$uid
But that is probably too complex and overthought. What do you think?
I don't think this is required, meh :-)
The only thing that comes to mind wrt the object path is that the object
path might be the identifier that we use for object caching. But then I
don't suppose subdomains can be renamed with the current code at all..