[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Antwort: RE: Antwort: RE: server side sorting & paging? [Virus checked]
-----Original Message-----
From: denis.havlik@t-mobile.at [mailto:denis.havlik@t-mobile.at]
>>>
>I would say it's very rare that any client wants to browse the complete
data.
>When was the last time you opened a paper telephone book and read it cover
to
>cover, let alone reading an entire single page of entries?
Well.. Probably never. I do use google a lot though, and I could imagine
other apps where zilions of results are returned, and I want to sort them by
some criteria and give the user a page of results a time back.
Maybe such apps simply shouldn't use LDAP backends, end of the story.
<<<
Once again, the information gathering and the information presentation are
two different operations. Scalability issues aside, combining these
operations on the server makes for a poor user interface. The #1 sin for a
user interface is to make the user wait, or to have sluggish performance. Any
time you make a user wait more than 100 milliseconds for visible response to
a command, your interface has failed.
When you rely on server-side sorting, that means the server must collect the
entire result set before any of it will be returned to your client. For your
google query with zillions of results, that could mean a very noticable delay
before anything comes back to give your client even a chance to begin
displaying the data.
In a good, responsive user interface, you present the data as soon as it
arrives, so the user never gets the feeling of having to wait. You sort the
data on the fly, inserting it into the display where it belongs. If it
belongs in a portion of the list that's off-screen, or already viewed, you
flag that portion to indicate that new data is present - the user can scroll
to it if they really want to see it. Most likely, if they've scrolled past it
already, they don't care to see it.
Fixed-size "pages" are a data view inherited from a paper-based world. You
have more options in a computer interface, and sticking to archaic models
doesn't make the best use of your available resources.
I'll say no more on this as we've wandered rather far from "OpenLDAP
Software."
>>>
In fact, I started thinking about this SSS for a completely different reason:
I need to compare two LDAP dirs, both of them have user data, and each user
has unique Personal number. It would be convenient to keep connection to both
dirs open, and then pick up user data one by one sorted by ID - that way it's
easy to see who's new and who's gone.
I can do it in other ways, but this triggered the curiosity, and so... As I
said, I'm in a learning mode. :-)
<<<
The total amount of work done for your task is the same in any solution - the
server must sort all of the entries, or the client must. But when the server
does it, that stops other clients from getting their work done.
>>>
>>PS: Yes, I can see that things get REALLY funny as soon as we start working
>>with references, i.e. as soon as the data isn't all on a single server.
>That realization should tell you something...
Well, it tells me that some things should not be done with LDAP. Having this
confirmed (or overrulled) by the folks who know LDAP better than I do is
fine.
<<<
I would have said: It means you can't rely on the server to sort, you have to
do it in the client anyway. There is no getting around the fact that it makes
the most sense to do it there.
>>>
What's confusing me is the fact that someone wrote the RFC 2891, and what's
even more confusing me is that Kurt apparently worked on VLV some time ago.
Maybe that looked like a good idea at first, but turned out to be a
BadThing(TM) in the end?
regards
Denis
<<<
There are far more RFCs written than are implemented or in use. Everybody has
to be in learning mode at some time or another. With that said, I have no
idea what happened to VLV, Kurt can answer that.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support