[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] VLV: a particular target entry
I agree with Kurt that positioning by DN would be useful, and it seems
simple to implement.
Another example of its use might be to maintain position in a list when
refreshing the list. If a particular item has been selected, if the list
is refreshed, one might expect that after the refresh, the item remains
selected (if it exists) and the view is positioned so that the selected
item is in the window.
John McMeeking
"Kurt D.
Zeilenga" To: "David Boreham" <david_list@boreham.org>
<Kurt@OpenLDAP.or cc: "ldapext" <ldapext@ietf.org>
g> Subject: Re: [ldapext] VLV: a particular target entry
Sent by:
ldapext-admin@iet
f.org
09/26/2002 06:47
PM
At 04:00 PM 2002-09-26, David Boreham wrote:
>> However, the new list shows "Pinapples, Hawaii" to
>> "Tangerines, California".
>>
>> The new view is not continuous with the prior view. There
>> is a discontinuity.
>
>Ah yes. We had this discussion a couple of years ago too.
I don't dispute that the problem was previously discussed.
>>Are you concerned about missing entries from the list in the general
>>case, or where the list is modified concurrently with the scrolling ?
I am concerned primarily by the latter.
If we look back at the scenario I described:
User is provided a view into a list showing "Apples, Washington"
to "Oranges, Florida". The user requests the list be scrolled
down expecting the new view to show "Oranges, Florida" to whatever.
(The application is designed to show overlap of one list
entry between views and the list is sorted first by "fruit"
and then by "state").
However, the new list shows "Pinapples, Hawaii" to "Tangerines,
California".
The obvious problem is that the server doesn't know what
actions the user has taken, it only knows what the parameters
the client provided to it. The current mechanism requires the
server to guess whether the new offset / content count
indicates a new (independent) positioning by their ratio
(where "jumping" to new view is expected) or they indicate a
scroll up/down action.
As long as the server has to guess, there will be problems.
An appropriate solution needs to avoid discontinuities,
allow for discontinuities to be detected, and provide
a means to address discontinuities.
Additionally, the solution should not require complex
state management. The solution should be "stateless".
I think an scrolling approach based upon select by DN
is not only an appropriate solution (as described above),
but also doesn't involve significant state management.
In fact, from a protocol perspective, the DN approach
is "stateless".
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