On Tue, Dec 16, 2014 at 02:26:22PM +0100, Pavel Březina wrote:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
Hi,
I have take the following tikcet that is about implementing D-Bus calls for
domains, users and groups. I have some questions.
https://fedorahosted.org/sssd/ticket/2150
*List and Find methods interface*
At this moment we implement all List* and Find* methods on
/org/freedesktop/sssd/infopipe and org.freedesktop.sssd.infopipe interface.
The patches I sent today enables having support for different interfaces on
/path and /path/*, therefore we can implement the methods as:
/infopipe/Users infopipe.Users.ListUsers()
/infopipe/Users/$UID user specific methods and properties
instead of:
/infopipe infopipe.ListUsers()
/infopipe/Users/$UID user specific methods and properties
I think it make sense. Is this something we want?
Yes, I like this suggestion better, too.
*Domains*
The interface from the design page is already implemented. Is there any
method or property that is missing?
I'm not aware of any. Maybe in the future, we may add some
online/offline status check, when we implement that in the deamon, but
for now I think we're good.
*Users*
Do we want also to have methods ListDomainUsers() and ListUsers() without
the name filter?
To list all? What about using '*' for that?
Do we want some other filter options as well?
In the design I wanted to keep the filtering simple. Unless we receive
some other requirements..
Should extraAttributes be present in Properties.GetAll() output?
Yes, I think it would be a bug if they're not :-)
What is UpdateGroupList() supposed to do?
Update the group property you asked about below. Basically re-run
initgroups().
Property groups - do we really want to return list of object paths instead
of pure group names? I think that more common use case will want only the
names. Or we can even implement both.
IIRC Stef requested object paths as being more common in the D-Bus
world.