RE: (ITS#7698) Multiple Paged search requests on one connection fail

[john.unsworth@cp.net]

Products other than browsers use LDAP servers. Our product is a meta
directory that watches for changes on multiple data sources (LDAP,
Databases, SAP, ...) and reconciles any changes across the complete set of
sources according to data filtering and transformation rules. However
sometimes it is necessary to read the whole data set - for example when a
new data server is added, or when changes may have been missed for any
reason, or when an 'audit' type operation is required to ensure that all
data sources are consistent. LDAP servers we connect to typically contain
thousands if not millions of entries. Reading the lot without paging -
although we can do it - is very inefficient both in terms of LDAP resources
and application resources.  The directory is read using multiple parallel
paged searches across different branches on a single connection. Every
directory we have used except OpenLDAP can manage this effectively.

In the case of OpenLDAP there is no LDAP changelog and so the only way we
have of discovering changes is to read the whole directory and compare with
what was read last time.

-----Original Message-----
From: Michael Ströder [mailto:michael@stroeder.com] 
Sent: 17 September 2013 20:20
To: john.unsworth@cp.net; openldap-its@openldap.org
Subject: Re: (ITS#7698) Multiple Paged search requests on one connection
fail

john.unsworth@cp.net wrote:
> I would also be interested to understand why " paged results is inherently
> flawed".

Although being the author of an interactive LDAP UI client I still wonder
why
people want paged results (or tree browsing).

If you have so many results you should narrow the search criteria.
Browsing/paging is pretty inefficient working style.

Ciao, Michael.