--- Begin Message ---
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Subject: Re: Paged Results and limits
- From: Pierangelo Masarati <ando@sys-net.it>
- Date: Fri, 09 Apr 2004 16:31:50 +0200
- Cc: openldap-committers@OpenLDAP.org
- References: <4076A119.4020509@sys-net.it> <6.0.1.1.0.20040409064553.0486ca50@127.0.0.1>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Kurt D. Zeilenga wrote:
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.
OK, so you suggest that the total entry count of pagedresults be
equal to hard limits.
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.
If the requested entry number is lower than the page size,
this already happens, but it's a trivial case. I can make it work
also the other way, e.g. do not return more than the requested
entries as a total count.
This means that we need to keep a running count of total
entries returned across page requests...
This is done in my last fix; I also added a special limit for
paged results which defaults equal to "any"; all I need to do
is make it default equal to the hard limit (I interpret pagedResults
as a request for a specific value of entries, so the hard limit should
apply). This allows fine grained crafting of limits for this type
of request, and by default will implement what you described above.
Watch for my next commit.
Ando.
--- End Message ---