[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] VLV: a particular target entry
I suggest we add more information on the intent of the contextID
(cookie) and state that servers choosing to not use it may run into
instability problems.
Jim
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/03/02 01:05PM >>>
At 11:49 AM 2002-10-03, Jim Sermersheim wrote:
>Help me understand the stability problem further. If the cookie
>mechanism is used, a server knows the last view that the client has.
If
>a client asks for a new view (by offset) that overlaps or adjoins the
>last view, the server should be able to provide contiguous
results--even
>when updates are happening.
First, note that the present cookie is optionally provided by
the server and optionally returned by the server. It's purpose
has been described to allow the server to make optimize processing
of related requests. It, however, hasn't been described as a
mechanism which the protocol relies on to address content
instability.
If servers were REQUIRED to provide a cookie and clients
were REQUIRED used the cookie in subsequent related requests, then
the cookie could be used to address the stability problem.
I would refer to this as a "state-full" approach.
However, the authors have stated that VLV could be implemented
in a "state-less" fashion. No cookies.
Either VLV is
stateful - some state is needed.
stateless - no state is needed.
Which is it?
>Jim
>
>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 10/01/02 09:09AM >>>
>At 07:21 AM 2002-10-01, David Boreham wrote:
>>> Do you not see that VLV is broken without selection by DN.
>>> That is, the VLV scroll up/down mechanism fails in the
>>> general case, e.g. when content is unstable.
>>
>>Highly unstable content isn't within the scope of this
>>protocol.
>
>Note that I did not say "highly unstable". I said "unstable".
>That is, one entry add/modification/delete is sufficient
>to cause this protocol to fail.
>
>>Directories typically don't have highly unstable content.
>
>But directories typically do change. And any change is
>sufficient to cause failure in this protocol.
>
>>Kurt: do you have a counterexample ? e.g. something
>>you tried to implement with the current protocol but failed
>>to get to work ? Tell us about it.
>
>Based upon my operational experience with implementing similar
>controls, it is obvious to me that the current protocol fails
>where contain is not stable. In particular, were DIT
>modification causes the positioning of entries in the list to
>shift.
>
>Kurt
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext