Subject: Re: [ldapext] VLV: a particular target entry

From: "David Boreham" <[email-masked]>
Date: Thu, 3 Oct 2002 15:16:00 -0700

> If every entry in the client's current view has vanished, you would just
> attempt a re-position based on their current requested offset. They
> would end up in a place that may or may not be confusing.

Indeed.

> In my mind, for this particular issue, there doesn't need to be any
> change to the VLV protocol. Only clarifications and further notes to
> implementers.

My point was that there is no general solution to the
dynamic list content problem, only various suggestions
to make it not so bad, in the abstract, with no cited
application where the problem has proven to arise in the
first place.

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 03 Oct 2002 15:51:16 -0700

>> would end up in a place that may or may not be confusing.

Or return an error.

>dynamic list content problem,

I believe there are at least two general solutions to this
problem.
  1) a cookie (stateful) approach which can be used to position the
  view based upon previous list state and returned results,
  2) a stateless approach which positions the view relative
  to a particular object in the list.

Both solutions, where continuity cannot be provided, can detect
the lack of continuity.

>only various suggestions to make it not so bad,

I disagree.  Both of the above approaches not only handle
minor list changes but deal with some major list changes...
and, where they cannot deal with changes, they can detect
that they cannot and return an error.  This is significantly
better ignoring the problem.

>in the abstract, with no cited

(Based upon your description of the Sun/Netscape server)
Take your address book client, select a view against the
Sun/Netscape server, add one entry from the list before
the target, then page down.  The provided view will skip
over one entry. That's a problem, it's real.

Kurt

---

From: "David Boreham" <[email-masked]>
Date: Thu, 3 Oct 2002 15:57:49 -0700

> over one entry. That's a problem, it's real.

In my limited world, this is _not_ a practical problem.

So...an entry which was just added to the directory
happens to not show up when a user pages down, where
it will if they subsequently page up again, or re-position.
The entry wasn't there a few seconds ago anyway, so 
where's the problem here ?

I will repeat: many years of practical deployment experience
has shown me that this is not a real problem.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 04 Oct 2002 01:07:39 +0200

> has shown me that this is not a real problem.

I can imagine that this is a serious problem in an administration 
application where the application user (e.g. a directory manager) expects to 
see the entries he added a few seconds ago in another window continously 
showing the list view.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 03 Oct 2002 16:34:37 -0700

>In my limited world, this is _not_ a practical problem.

Maybe so.  But we need to design standard track protocols
such that they work well on the Internet for a wide
range of applications.  Maybe for your users and their
applications, this is not a problem.  However, I can see
that for other applications this would be a major problem.

Now, its don't necessary don't have to expand the
applicability of a protocol, but authors do need to make
sure that the known limitations your protocol are clearly
stated.

>happens to not show up when a user pages down,

It actually far more likely to skip over existing entries.

>where it will if they subsequently page up again, or re-position.

When they subsequently page up, maybe one entry before the
target is deleted, so the entry is skipped again.

>where's the problem here ?

I scroll down, the entry I'm looking for isn't in the view.
I scroll up, the entry I'm looking for isn't in the view.
I naturally assume the entry isn't in list when in fact
the entry has been in and continues to be in the list.
Problem?  well, that depends on what action I take (or
don't take) based upon the entry not appearing on the list.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 03 Oct 2002 17:00:22 -0700

>sure that the known limitations your protocol are clearly

Sorry, this should read:
  Now, it's not necessary to expand the applicability
  of a protocol, but the authors do need to make sure that
  the known limitations of the protocol are clearly
  stated.

Kurt