Le 02/07/15 11:14, Kiran Ayyagari a écrit : > Hi Yaning, > > On Thu, Jul 2, 2015 at 4:28 PM, Xu, Yaning <yaning...@intel.com> wrote: > >> Hi Kiran, >> >> >> >> 1. The administrator may need to list all principal names, and then >> use the principal name he is interested in to get the Identity; >> >> 2. There may be too many principals to scan at once, so the system >> may need to get only a part of them at once, as Stefan pointed out; >> >> 3. We need to make Kerby compatible to Krb5, and it has implemented >> this interface as list_principals >> http://web.mit.edu/KERBEROS/krb5-1.12/doc/admin/admin_commands/kadmin_local.html >> ; >> > ic, so here is the case, it is mainly for the kadmin client and I would > prefer if kadmin takes care of > sorting and paginating after retrieving the principals rather than > offloading this to backends. > > The primary reasons is not all stores that are used by IdentityBackends may > support sorting or > pagination, for example not all LDAP servers support sorting and many > database libraries do not > support pagination(this is a client thing). > > I would like to propose an alternative design: > > Add search functionality to the IdentityBackend, i.e it accepts a search > pattern and return a Cursor > then kadmin will browse this cursor and prepares a suitable view of > principals. > We can have a search limit in this interface but we don't need a start > position cause the client can > navigate using Cursor (when the cursor implementation supports).
I tend to disagree with Kiran, here. If a server does not support 'sort' and 'paged search', then there is no mean to use it as a backend. AFAICT, most of the existing LDAP server on the market support both controls. In any case, don't implement it on the client side : with millions and candidate, it will not only be slow, but it will also eat a hell lot of memory.
