Subject: [ldapext] re: negative offsets revisted

From: John McMeeking <[email-masked]>
Date: Fri, 27 Sep 2002 08:15:22 -0500

I can live with the current "byoffset" positioning.  If the list is stable,
it is a simple matter to move to any position in the list with the current
"byoffset" specification.  If the list is not stable, any attempt to do
relative movement within a result set is likely to yield unexpected
results:
- moving back from the end of the list, in a list that is growing at the
tail, could move you past the old end of list.
- moving forward from the start of the list, in a list that is growing at
the head, could move you prior to the old starting position.
- in general, even requesting the same position twice in a row could give
you quite different "views"

John  McMeeking

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "David Boreham" <[email-masked]>
Date: Fri, 27 Sep 2002 07:58:26 -0700

> relative movement within a result set is likely to yield unexpected

Yes, 'perfect' behavior under a highly dynamic list is not a
goal for VLV. It was designed for the applications cited:
address book and directory management apps, where the
list is expected to be nearly static. It has proven to be
useful for these applications over a long implemention
and deployment history.

Now, in the dim and distant past I had worked with a
couple of proprietary address book interfaces, which had
the notion of a bookmark and the ability to seek to a
previously visited place and sync multiple views exaxctly.
To my knowledge, these features were never used.

VLV was intended to be reasonably easy to implement
in a range of different server architectures, and intended to
perform well in all those servers. While the 'seek by DN'
concept sounds attractive in the abstract, my belief
is that it is a) not needed for the target applications
and b) prone to performance issues. For example, a server
implementation may find it inconvenient to use DN as the
key---perhaps the server has some other internal unique ID
which it would rather use. Now we need to either make
the key opaque (this is what MAPI does, btw), or we need
to build a translation between DN (ordered) and the internal
UID. Given the dubious benefit to the requested feature in
the target application set, it does not seem worth the trouble.

Should a new class of application emerge, for which this
feature is compelling, then I see no reason not to press ahead
with a VLV2 protocol which supports it.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 27 Sep 2002 08:08:15 -0700

At 07:58 AM 2002-09-27, David Boreham wrote:
>goal for VLV.

One entry add/deletion is enough to cause VLV to behave oddly!

Kurt