Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <47E6F325.60807@symas.com>
Date: Sun, 23 Mar 2008 17:17:41 -0700
From: Howard Chu <hyc@symas.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686;
 rv:1.9b5pre) Gecko/2008030700 SeaMonkey/2.0a1pre
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [LDAP] [Client] Client side Cursors can help w/ LDAP paging and
 notification
References: <a32f6b020803221830k43d62afl76b66218e5ef70a4@mail.gmail.com>
	 <d45b08f00803230235r5d374ee2t6e5fe3d4b1aec33c@mail.gmail.com>
	 <47E62DA5.1060808@symas.com>
 <a32f6b020803231047l54982b89w3e120dc4ff98bc29@mail.gmail.com>
In-Reply-To: <a32f6b020803231047l54982b89w3e120dc4ff98bc29@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam_score: -4.8
X-Spam_score_int: -47
X-Spam_bar: ----
X-Spam_report: Spam detection software,
 running on the system "lirone.symas.net", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  Alex Karasulu wrote: > On Sun, Mar 23, 2008 at 6:15 AM,
 Howard
	Chu <hyc@symas.com > <mailto:hyc@symas.com>> wrote: > > Using cursors for
	walking entry lists (and saving the cursor state) is > certainly useful
 inside
	the server, but there's nothing you can > safely gain > from the client side.
	> > It kind of sounds like you're talking about Virtual List Views, not >
	paged > results. Remember that search responses in LDAP/X.500 are unordered
	by > definition. Therefore it makes no sense for a standards-compliant >
	client to > send an initial request with a Paging control saying "start at
	responses > 200-300" because the order in which entries will be returned
	is not > defined. > You need something like VLV which requires SSS to even
	begin > thinking about > this; it's not a job for Paged Results. > > > Yes
	you're totally right,
 I've confused the two controls. Thanks for the > correction.
	> > Either way we still need to implement both. Does OpenLDAP implements
	> both of these controls? Any opinions or advice regarding implementation
	> and or the actual utility of these controls? [...]
	Content analysis details:   (-4.8 points, 5.0 required)
	pts rule name              description
	---- ----------------------
 --------------------------------------------------
	-1.8 ALL_TRUSTED            Passed through trusted hosts only via SMTP
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
	-0.4 AWL                    AWL: From: address is in the auto white-list
X-Virus-Checked: Checked by ClamAV on apache.org

Alex Karasulu wrote:
> On Sun, Mar 23, 2008 at 6:15 AM, Howard Chu <hyc@symas.com
> <mailto:hyc@symas.com>> wrote:
>
>     Using cursors for walking entry lists (and saving the cursor state) is
>     certainly useful inside the server, but there's nothing you can
>     safely gain
>     from the client side.
>
>     It kind of sounds like you're talking about Virtual List Views, not
>     paged
>     results. Remember that search responses in LDAP/X.500 are unordered by
>     definition. Therefore it makes no sense for a standards-compliant
>     client to
>     send an initial request with a Paging control saying "start at responses
>     200-300" because the order in which entries will be returned is not
>     defined.
>     You need something like VLV which requires SSS to even begin
>     thinking about
>     this; it's not a job for Paged Results.
>
>
> Yes you're totally right, I've confused the two controls. Thanks for the
> correction.
>
> Either way we still need to implement both. Does OpenLDAP implements
> both of these controls? Any opinions or advice regarding implementation
> and or the actual utility of these controls?

OpenLDAP currently has a no-op implementation of SSS and no VLV. There's been 
some discussion about implementing them, but no one has been interested enough 
to do it so far. The main problem being that SSS gets to be rather annoying in 
the context of a truly distributed DIT, plus the CPU time involved makes the 
whole proposition unscalable. This is one of those cases where, given 100s of 
clients talking to a single server, it makes more sense to distribute the work 
to the clients than to run hundreds of sort variations on the single server.

Netscape/iPlanet obviously took the opposite view, and decided there would 
probably be small enough variation in the types of searches being used that 
you could index them explicitly to avoid the overhead. We may follow on that 
road as well, and just return UnwillingToPerform for searches that were not 
indexed.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/