Stefan Seelmann wrote:
Emmanuel Lecharny schrieb:
Hi guys,
as I'm busy implenting this control,
Cool
1) considering that we have a server sizeLimit, a request sizeLimit and
a page size limit, I'm wondering if we can simply ignore the request
size limit. The page size limit can change, even if the paged result is
being processed, but the RFC says "If the page size is greater than or
equal to the sizeLimit value, the server should ignore the control as
the request can be satisfied in a single page". Should I consider that
the 'sizeLimit' is the request sizeLimit ? My personnal bet is : yes.
Yes, I would say the 'sizeLimit' is the request sizeLimit.
I think we should not ignore the requst sizeLimit, I would consider it
as client-side limit for the complete search over all pages.
Say the request sizeLimit is 10 and the page size is 8 for both requests
then the first result contains 8 entries and the second contains 2
entries plus a LDAP error #4.
Makes perfect sense. So we will have to remember the number of already
returned entries, and compare it
to the sizeLimit. Fine.
3) regarding the search request immutability : it's pretty hard to check
that the filter hasn't changed, as it may be a complex one, with a
different structure and a a different order. I think that this
constraint is fully absurd, as the client will obviously create one
request, and send a null cookie every time it will send a new paged
search, so I don't see the validity of such a check. Nevertheless,
should we try to implement such a check ? My personal guess, again, is
that it's useless.
To check if the filter changed logically is really complex. I think you
could just check if the string representation or the bytes the are
received were changed.
This is what I currently do. There is nothing more I can do...
I'm also interested to have some feedback about how this control is
handled by the other ldap servers, considering the many factors
influencing this control :
- internal server size limit
Here different implementations are different.
- OpenLDAP just stops if the server side limit is exceeded.
I thought you can define soft and hard limit... I have to check in my
favorite OpenLDAP book 'Mastering OpenLDAP'.
- For MS AD has a default server side limit of 1000, but when this
control is used you could get more
Which violates the spirit of this limit... Thanks, AD !
- how many of such paged search can be handled for a single client
Infinite?
Costly ... Currently, we don't have any limit, but at some point, we
will need to discard some old searches, as each of them eat a big chunk
of memory. I would say that a circular list of 10 paged search request
should be a valid default. It may be configurable, too.
The main issue I have atm is that I have to implement a mechanism to
discard timeout-ed requests.
- what happens when we send a bad cookie to the server
Either start a new search or return an error
I think that sending an error is better.
- what happen when we play with the sizeLimit parameter
You mean the request sizeLimit? If it is changed it should be considered
as a new search.
You're right !
Last, not least, as we are using cursors to get the entries from the
backend, we are able to move forward or backward. It would be
interesting to extend this control to allow a backward pagedSearch (for
instance, providing a negative paged size). Would it be interesting ?
There is another control for this: VLV, see [1]. But is also need
server-side sorting.
True ! I forgot about this guy...
Thanks Stefan, very interesting responses ! I was running in circles, I
start to see the light now :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
