On Tue, Jan 06, 2015 at 11:31:55AM +0100, Pavel Březina wrote:
>>*Users*
>>Do we want also to have methods ListDomainUsers() and ListUsers() without
>>the name filter?
>
>To list all? What about using '*' for that?
We can implement it this way internally, but exposing an easier way to the
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 suggested
we may want to require the minimum filter length since the number of users
may be very high. The maximum D-Bus message is 128MiB so I think we are good
there but I think it can be very time consuming to return all users without
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
overhead?
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
resume iteration..
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 expression
efficiently as Dmitri would be quite problematic since ldb doesn't support
regex lookup thus we would have to do this ourselves and therefore we would
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 place)