On Wed, Jan 07, 2015 at 11:07:05AM +0100, Pavel Březina wrote:
On 01/06/2015 03:59 PM, Dmitri Pal wrote:
>On 01/06/2015 05:54 AM, Jakub Hrozek wrote:
>>On Tue, Jan 06, 2015 at 11:31:55AM +0100, Pavel Březina wrote:
>>>>>Do we want also to have methods ListDomainUsers() and ListUsers()
>>>>>the name filter?
>>>>To list all? What about using '*' for that?
>>>We can implement it this way internally, but exposing an easier way
>>>consumers is nice, imho.
>>I'm not too opposed, although I prefer minimal APIs.
>>>However, do we actually want to allow to list all users? As Dmitri
>>>we may want to require the minimum filter length since the number of
>>>may be very high. The maximum D-Bus message is 128MiB so I think we
>>>there but I think it can be very time consuming to return all users
>>>some sort of paging.
>>This feature is internally dependant on enumerate=true, where we already
>>store all standard POSIX attributes (struct passwd, struct group)
>>in-memory, do you think the D-Bus "enumeration" provides that much
>>Paging would be really complex, we'd need to store the full results
>>in-memory per-client anyway and then pass around some kind of cookie to
>>In a centralized environment, I wouldn't expect the listing commands to
>>be used that commonly. Greeters or login managers (gdm) would typically
>>use the cached users instead. Some applications (Hi, RHEV-M!) choose to
>>display all their users in some kind of table and then I would expect
>>them to implement paging themselves:
>>for letter in a..z:
>> users = ListUsersByNameFilter($letter)
>>>>>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..
>>>Yes, you suggested to allow only asterisk. Implement full regular
>>>efficiently as Dmitri would be quite problematic since ldb doesn't
>>>regex lookup thus we would have to do this ourselves and therefore we
>>>loose indices, or am I wrong?
>>I guess we'd have to grab all the entries and filter them ourselves..
>>(Yes, this is the reason I chose the asterisk notation in the first
>>sssd-devel mailing list
>- IMO having a full regular expression support will be an overhead.
>- "Begins with" filtering with * to indicate the remaining part is good
>- I do not think we should rely on enumeration. I think we should do a
>lookup since these operations will be rare.
Yes, but as a second step, because back end currently only supports
looking up a single entry (name=dpal) or all of them (name=*) which
But requiring enumeration /now/ and working on the filter-based lookups
later would allow us to finish the dbus responder changes already.
In my opinion:
List methods (i.e. those that return list of objects) should return only
those objects that are already cached. If the caller wants all of them,
enumeration should be turned on.
I think we'll need to add filter-based lookups as well to the back end.
Requiring enumeration is simply a no-go in large production systems.