Re: (ITS#3939) min/max function extension to LDAP protocol

[Kurt@OpenLDAP.org]

Well, what I noted was that there was an existing protocol
mechanism to request return the entry with the lowest/highest
CSN.

I pretty much ignored most of rest of your post as it didn't
make much sense to me at the time (and still doesn't).

The consumer needs to very careful in how it treats the sync
cookie, and likely we're linking it too closely with CSNs.
Recall that the sync protocol itself has no concept of a CSNs,
use of CSNs is an implementation choice and details implementation
specific.   While our provider places a CSN in its cookie, the
consumer really shouldn't be parsing the CSN out of the cookie,
and, if it does, it shouldn't use it for anything.  The
consumer should regard the cookie as an opaque value.
(While we should allow consumer construction of a cookie, but
we should avoid consumer extraction of CSN from the cookie.)

The consumer's context CSN should be independently managed,
and then, only if the consumer is configured as a provider.

Kurt

At 10:19 PM 8/19/2005, Quanah Gibson-Mount wrote:


>--On Tuesday, August 16, 2005 11:58 AM -0700 Quanah Gibson-Mount <quanah@stanford.edu> wrote:
>
>>
>>
>>--On Tuesday, August 16, 2005 11:53 AM -0700 "Kurt D. Zeilenga"
>><Kurt@OpenLDAP.org> wrote:
>>
>>>LDAP already provides a mechanism for performing this function,
>>>by use of the paging (1 page of 1 entry) [RFC2696] and sorting
>>>[RFC2891] controls.  Of course, slapd(8) does not support the
>>>sorting control.
>>>
>>>Given this is (or can be assumed to be) a request for enhancement
>>>to OpenLDAP Software and not a request to enhance LDAP (if the
>>>latter, the OpenLDAP ITS is not the right place to request
>>>enhancements to LDAP be made), I suggest this ITS be regarded
>>>as a request to implement the sorting control.
>>
>>Yes, this is a request to enhance OpenLDAP appropriately. :)
>
>Actually, after talking to Howard, I believe the above controls aren't sufficient.  The whole problem is candidate generation.  Now, with BDB, it should be possible to get the min and max values from the first and last marker in the entryCSN index database, since it can only be indexed with equality.  So for syncrepl to ever really be efficient for servers that are stopping/starting after deletes or multiple modifies to the same entry, it needs a way to get those values.  This completely avoids any candidate generation, and allows the syncprovider to quickly let the replica know if its CSN is out of date.  How one would implement that inside the LDAP specs is a different issue. ;)
>
>--Quanah
>
>--
>Quanah Gibson-Mount
>Principal Software Developer
>ITSS/Shared Services
>Stanford University
>GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
>
>"These censorship operations against schools and libraries are stronger
>than ever in the present religio-political climate. They often focus on
>fantasy and sf books, which foster that deadly enemy to bigotry and blind
>faith, the imagination." -- Ursula K. Le Guin