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:
>>>>> I created a new design page to reduce size and increase readability
>>>>> the original one. I would like to keep DBusResponder page mainly as
>>>>> crossroad with links to other pages in the future so it is not
>>>>> with too many details on everything.
>>>>> I will replace user and group design in DBusResponder with the
>>>>> link if you agree:
>>>>> It should cover everything we agreed on. If not, please tell me and
>>>>> will add it.
>>>> New iteration is available at:
>>> 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:
>> 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..
OK. I amended the design page to reflex /ifp/Users/$DOMAIN/$UID object path.