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: > >>>>>*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) > >>_______________________________________________ > >>sssd-devel mailing list > >>sssd-devel@lists.fedorahosted.org > >>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel > > > >Several points: > > > >- IMO having a full regular expression support will be an overhead. > >- "Begins with" filtering with * to indicate the remaining part is good > >enough > >- 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 triggers enumeration. 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. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
