Fwd: Re: Paged Results and limits

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

>Date: Fri, 09 Apr 2004 07:02:50 -0700
>To: Pierangelo Masarati <ando@sys-net.it>
>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
>Subject: Re: Paged Results and limits
>Cc: openldap-committers@OpenLDAP.org
>Comment: openldap-committers mailing list <http://www.OpenLDAP.org/lists/>
>List-Archive: <http://www.OpenLDAP.org/lists/openldap-committers/>
>
>I do not think the paged results mechanism should be
>viewed as a mechanism for going around server-side limits.
>It should viewed as a flow-control mechanism.
>
>If the server limits a client search operation to N entries
>and M candidates, these limits apply whether the results
>are paged or not.
>
>Likewise, when a client provided size limit, I think this
>should apply to the total result set as well.  This makes
>sense because the client is required to provide the size
>limit up-front (on the first operation) and is not allowed
>to change it on page requests.
>
>This means that we need to keep a running count of total
>entries returned across page requests...
>
>Kurt
>
>At 06:11 AM 4/9/2004, Pierangelo Masarati wrote:
>>I'm about to complete the commit of additional limits for paged results control.
>>Currently, the control is only implemented in back-bdb, but I'm moving the limits
>>on the control outside of it, into the limits_check() function that sets the time and
>>size limits for the execution of a single search (which corresponds to one page
>>when the control is used).  In the future, this could help in moving the control to the
>>frontend, if advisable.
>>
>>The current implementation interprets the size limits as a size limit on the single
>>page, so a request for a page size that is smaller than the limit results in a search
>>that can span the entire database without any limits, apart from the "unchecked"
>>test on the number of candidates.
>>
>>The pagedResults control enabled two extra limits: one on the max size of a single
>>page that was different from the basic search size limit, and the other intended as
>>a means to hide the estimate of the remaining entries to be returned.
>>
>>I'd leave this behavior as the default, and add a new limit on the total number
>>of entries that a search with the pagedResults control can return.  I'd interpret
>>the request for a page as an explicit limit set by the user, so the "hard" limits are
>>used instead of the "soft", and the new "prtotal" limit as a means to introduce
>>an overall "hard" limit.
>>
>>All the limits are now moved to the limits_check() function, so the search functions
>>only see a size limit and act accordingly.
>>
>>Commit to come soon; still working on cleanup.
>>
>>Comments?