Kai, Thanks for your suggestions. It's good to me.
Yaning -----Original Message----- From: Zheng, Kai [mailto:kai.zh...@intel.com] Sent: Friday, July 03, 2015 2:37 PM To: Apache Directory Developers List Subject: RE: How to implement getIdentities(int start, int limit) more effectively Thanks all for the thoughts and suggestions. Yaning, your plan looks good to me, easy to go for the initial version. If nobody objects, would you mind proceeding to: 1. Fire an issue to remove the paged getIdentities(offset, limit) and have the non-paged one getIdentities() just to return all entries? I thought it's good to have for our initial release, we would evolve quickly to have new version to replace it. 2. Fire an issue to support cursor in the backend API, targeting future version. 3. Fire another issue to optionally support sort and paged search, targeting future version. Another idea is, how MIT Kerberos handling this? I know it supports many backends, like SQL and OpenLDAP. Would be good to take a look at it. Thanks. Regards, Kai -----Original Message----- From: Xu, Yaning [mailto:yaning...@intel.com] Sent: Friday, July 03, 2015 1:43 PM To: Apache Directory Developers List Subject: RE: How to implement getIdentities(int start, int limit) more effectively Thanks Emmanuel and Kiran for the discussion! As you suggested, it would be good to support cursor, with sort and paged search favored. It looks great to me to have. I'm wondering if it's easy to implement the great features for all the existing backends in the first version. I agree the current paged getIdentities API is problematic, as you discussed, because it may be not doable for some backends. On the other hand, there may not be so many principals for us to worry about considering the initial version. Please note even we allow to get all the identities once a time, only principal names are required to return, so memory cost may not be too much. So is it okay that we remove sort and paged getting support from the APIs and just use getIdentities() to get all principal names in the first version, and leave the great features like sort, paged and cursor support for the following version? Hope this plan sounds good to all of us and easy to go. Thanks! Regards, Yaning -----Original Message----- From: Emmanuel Lécharny [mailto:elecha...@gmail.com] Sent: Thursday, July 02, 2015 7:56 PM To: dev@directory.apache.org Subject: Re: How to implement getIdentities(int start, int limit) more effectively Le 02/07/15 13:25, Kiran Ayyagari a écrit : > On Thu, Jul 2, 2015 at 6:05 PM, Emmanuel Lécharny > <elecha...@gmail.com> > wrote: > >> 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. >> > this is not just for LDAP servers, but any of the 'store's that are > used by Kerby say, there is one using Mavibot, we need to fetch *all* > and perform a search cause Mavibot doesn't natively offer a > substring/wildcard search. True. I was specifcially speaking about LDAP backend, I should have be explicit. > >> 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. >> > here the client is not just authenticating but is is an admin UI for > Kerby's database, this client can sort, search and paginate perhaps > with a wrapper backend that does all the functionality. > > My idea is not to enforce this requirement on each backend implementation. I'd rather suggest that the API expose a Cursor. The backends that support Sort and Paged Search would be favored, and the others, well, they will have to implement the Cursor interface.
