Re: [ldapext] re: negative offsets revisted

["David Boreham" <david_list@boreham.org>]

> 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:

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.



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext