Subject: [ldapext] VLV: absolute position of the list (negative offsets revisited)

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Sep 2002 12:10:11 -0700

VLV currently allows the list to be positioned (in addition
to other means) by an absolute offset from the head of the
list.  That, the client can send byoffset.contentCount=0
and byoffset.offset of some offset into the list.  This
allows the client to select the Nth entry from the beginning
of the list.

An application which offers a paged interface to the use
can use this feature to offer direct navigation to the
Nth page (from the head of the list) even where the
current content count is unknown (or unstable)

I presume there are other uses of absolute positioning.

Just as useful would be support direct navigation to the
Nth to Last Page even where the current content count is
unknown (or unstable).

Currently to select the Nth to Last Page, the client has
to reverse the list order, obtain the Nth Page, and reverse
the entries in the page.  This is expensive.

The VLV operation should allow the client to select the Nth
entry from either end of the list in a natural way.

The positive (head) and negative (tail) offsets are a common
approach used in GUI list view widgets.  Since VLV's design
is based upon the list view metaphor, I think it natural to
modify VLV to support both positive and negative offsets.

It has been argued by some that absolute positioning is not
useful.  If consensus is that absolute positioning is not
useful, then I would propose that VLV not standardize an
absolute positioning mechanism.  However, if consensus is
that absolute positioning is useful, I believe VLV should
support both absolute position from either end of the list.

That is, neither or both.  I prefer both.

Kurt

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

---

From: "David Boreham" <[email-masked]>
Date: Thu, 26 Sep 2002 12:23:36 -0700

> current content count is unknown (or unstable)

Note that it is a non-goal of VLV to implement
the feature set of the simple paged results control,
or to implement paging. It's designed to implement
scrolling list views.

> Nth to Last Page even where the current content count is

Just as useful as something which was only presumed ?

> the entries in the page.  This is expensive.

Please supply an example of where this is useful.

> modify VLV to support both positive and negative offsets.

Is this the time to be changing the prototol ? (we're in third last call, no
?).
I think that any big change like this belongs in some VLV2 protocol.
Or can you suggest a way to achieve what you want but retain
compatibility with the folks who took the time to participate in the
standards process and develop interoperable implementations ?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Sep 2002 13:03:40 -0700

At 12:23 PM 2002-09-26, David Boreham wrote:

>or to implement paging.

I obviously don't share your view as to the goal of
this work.

This WG was chartered to produce a standard track
specification "to allow a client to retrieve search
results one page at a time".  VLV was suggested as an
alternative approach to meet the WG meet this WG goal
and the WG has taken this approach to meet its goal.
However, the WG goal is unchanged.  It is still to
provide a standard mechanism "to allow a client to
retrieve search results one page at a time".

The simple paged results control was published as
Informational, not Standard Track, under the assumption
that VLV would obsolete it.

>It's designed to implement scrolling list views.

It also designed to support absolute positioning.  That
feature however is flawed in that it only allows positioning
from the head of the list.  This flaw is easily rectified.

Kurt

---

From: "David Boreham" <[email-masked]>
Date: Thu, 26 Sep 2002 13:19:34 -0700

> I obviously don't share your view as to the goal of

It's not a question of sharing opinions or not, it's a simple fact
that at an IETF meeting, I think in 1999, this was discussed
and rejected as a goal. Personally I was arguing on the
same side you now take. But the decision went the other way.
There were folks at that meeting with some implementation
experience with SPaged, who cited many reasons why
VLV couldn't trivially be extended to support an SPaged
superset. At the time I found their arguments persuasive
and gave up arguing the position which you are not advancing.

> retrieve search results one page at a time".

Fine with me. But this isn't VLV.

> that VLV would obsolete it.

Hmm...who assumed this ? I guess I wasn't at that meeting
and didn't see the list discussion on this subject.

> from the head of the list.  This flaw is easily rectified.

While reataining backwards compatibility with existing
implementations ? If so then go ahead and suggest new
text to allow this. You still haven't supplied an example
where this would be useful, so I'm not sure how 
you'd fare in getting agreement to change the document
at this stage, even if you retain compatibility with 
existing implemetations.

---

From: "David Boreham" <[email-masked]>
Date: Thu, 26 Sep 2002 13:22:43 -0700

> and gave up arguing the position which you are not advancing.

That should be ....position which you are _now_ advancing.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Sep 2002 14:07:49 -0700

At 01:19 PM 2002-09-26, David Boreham wrote:
>implementations ?

Backwards compatibility with early implementations is
a minor factor in determining which technical approach
should be taken.

As far an example, I described an paging example in a previous post.
You've dismissed this example as being beyond the scope of VLV.

 From this, I presume would dismiss any absolute positioning
example I offered as well.  I, however, believe that absolute
positioning has been to be useful in a number early
implementations of VLV.

Do you believe opposite, that is, operational experience with
early implementations of VLV have shown that absolute positioning
is not useful?

Kurt

---

From: "David Boreham" <[email-masked]>
Date: Thu, 26 Sep 2002 14:31:16 -0700

> a minor factor in determining which technical approach

You are three years too late to be talking like this.

> You've dismissed this example as being beyond the scope of VLV.

Correct.
 
> early implementations of VLV have shown that absolute positioning

Again correct. 

I had never thought of, not heard anyone suggest, the 'seek by DN'
feature you're asking for, until now. And as I say, I can't say that 
it's totally useless. But I'm certainly not seeing the compelling value.

Here's a straw-person: someone implemets an address book
application which uses VLV to scroll around in a big list of
entries. They want to implement a 'bookmark in the list' UI feature
where the user can mark a specific entry, then later (perhaps
years later), they can zip right to that entry in the list again.

Hmm...I don't know---somehow I don't see that feature making
it past the usability folks. Can someone think of a _more_ useful
application of 'seek by DN' ?

I might be able to see some non-UI applications where VLV is
somehow used as part of a sync facility. But then we run into
more goals problems in that VLV isn't designed to be used as
a syncronization mechanism.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Sep 2002 15:56:20 -0700

An application has multiple list views each ordered by different
criteria and allows the selection of an entry in any list to
cause all the other lists to be re-centered about that selection.
For example, this could be used to compare the seeding of
tennis players in different tournaments (each list showing
the seeding for a particular tournament).  In GUI terms, I
believe this is referred as synchronized list views.

Kurt

---

From: "David Boreham" <[email-masked]>
Date: Thu, 26 Sep 2002 16:02:02 -0700

> believe this is referred as synchronized list views.

Ha ! That's a pretty good one.

Sadly nobody has ever suggested doing this with VLV before now.

It sounds like an excellent feature for VLV2 though.