directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: How to implement getIdentities(int start, int limit) more effectively
Date Sat, 04 Jul 2015 13:27:54 GMT
Thanks Emmanuel for the further discussion.

>> My percezption is that the getIdentities() method should be made specific, per backend.
If a backend supports paged search and sort, fine, iyt can use it. If it's not, then it should
use a default implementation. In any cases, the user should not be aware of what's going on
behind the curtain.
Sounds good. One thing is we need a mechanism to let the client be able to aware what's the
capabilities a backend is of, paged search, sort and etc. If the client isn't able to aware,
how it make use of it.

>> The best way to acheive this is to have the getIdentities() return a Cursor, which
can be handled by any client.
As I said before, the cursor or iterator (proposed by Stefan) looks good to have. My only
question is, could we delay this to next release? You may be noted that it's not so easy for
us in short time, we have quite a few backends, and quite a few client calls to use the related
API. We should be able to get the most required things done and have the first release sooner
and better. Please note backend APIs are internal ones, no worrying for admin and end users
if we have.

>> All in all, define a getIdentities() interface, with an abstract implementatiuon
that fetches everything, and specific implementations that bypass this abstract implementation.
Yeah, agree. Again looks good to me.

Would you agree with the plan? Thanks.

Regards,
Kai

-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com] 
Sent: Friday, July 03, 2015 3:53 PM
To: dev@directory.apache.org
Subject: Re: How to implement getIdentities(int start, int limit) more effectively

Le 03/07/15 08:49, Xu, Yaning a écrit :
> Kai,
>
> Thanks for your suggestions. It's good to me. 

My percezption is that the getIdentities() method should be made specific, per backend. If
a backend supports paged search and sort, fine, iyt can use it. If it's not, then it should
use a default implementation. In any cases, the user should not be aware of what's going on
behind the curtain.

The best way to acheive this is to have the getIdentities() return a Cursor, which can be
handled by any client. This cursor will allow the user to move forward or backward, regardless
of the number of elements in the cursor. You can have a look at the Cursor interface we are
using in ApacheDS :
http://svn.apache.org/viewvc/directory/shared/trunk/ldap/model/src/main/java/org/apache/directory/api/ldap/model/cursor/

Side note : in the SQL world, this is the same approach. Once common mistake though in this
world, when design (G)UI which expose pages of elements taken froma  cursor is to proceed
in two steps :
- first do a SELECT COUNT(*) WERE blah
- second, depending on the number of elements, proceed with a single page, or manage pagination
locally, with a second request to the server, fetching the real entry.
This is *idiotic* ! Doing that, you make the server do the same work twice : the SELECT COUNT(*)
is as costly as the second request, and it's totally useless, unless you really want to expose
the number of elements on the screen, which is rare. The rational is that when you do a normal
request, the Cursor API allows you to define the number of elements you'll get back on the
client side (default to 10, most of the time).
That means the cursor implementation on the client side will cache N elements, no matter what,
because the server will send N elements anyway.

All in all, define a getIdentities() interface, with an abstract implementatiuon that fetches
everything, and specific implementations that bypass this abstract implementation.

Mime
View raw message