[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] VLV: a particular target entry
The original purpose of the cookie was to provide a way for a server to
associate a list with a client/connection. The problem was that a client
could be maintaining two VLV lists on the same connection, using the
same search criteria. In order for the server to perform certain
operations (like consistent page up/down) it was neccessary to add the
cookie so that the client's views could be known to the server. Novell
is the one that requested it, and it wasn't to solve any performance
issues.
The reason it was added as an optional component was to not cause
backward compatability problems with implementations that existed before
its introduction.
This should all be captured in the archives.
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