directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xu, Yaning" <yaning...@intel.com>
Subject RE: How to implement getIdentities(int start, int limit) more effectively
Date Fri, 03 Jul 2015 05:43:22 GMT
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:elecharny@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 
> <elecharny@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.xu@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.

Mime
View raw message