- From: Jim Davis <jdavis@coursenet.com>
- Date: Tue, 13 Apr 1999 10:24:36 -0700
- To: w3c-dist-auth@w3.org
At 02:22 PM 4/13/99 +0000, John Stracke wrote: >Jim Davis wrote: > >> In my opinion, a server that wished to provide three distinct sorted views >> on one underlying collection would best do it by advertising three distinct >> collections, each supporting exactly one sort,e g. >> ... >... this approach requires the server to know that it's being a message >forum; it has to include code to render these ordered collections. We are rapidly falling down a slippery slope along the following trajectory 1) client-side sorting 2) server-side sorting (server chooses) 3) server-side sorting (client chooses) ACR provides #1 now. Someone (I forget who) suggested that for those servers that maintain a sort anyway, they may as well be able to advertise that sort. Thus #2. The example offered to justify this was a mail server. I tried to show why this example was not very useful. Now you seem to be asking for the ability for the client to tell the server a) sort this collection using this ordering b) maintain this sort in the future I object to this 1) It's an unreasonable burden on the server. it's just as easy for the client to sort as for he server to sort, and there are more clients than servers. 2) It leads to a further slippery slope. If the server is expected to sort based on arbitrary sort identifiers, than why not ask it sort based on arbitrary DASL expressions, or for that matter arbitrary download Java expressions? 3) There's no demonstrated need. it's certainly not sufficient to construct a mail server. >Assuming the human speaks English. Anyway, I wasn't intending that the sorting >mechanism be exposed to the user; you'd click on a sort criterion and see your >messages get reordered, much as in an ordinary mailer. This will certainly be done client side for best speed. That's how modern day browsers do it (e.g. Eudora). You would not want to wait for a round trip. In summary, I still see no need for a collection that is sorted server side (what you might call a "live sort") to advertise its sorting, nor a need for the client to tell the server the live sort to be used. > (A nice DASL extension might be a way for the client to tell the >server, "I >expect to make this query frequently; you might want to keep an index for it.") That's an interesting idea but I hope you won't be offended if I ask to put it off until the base level of DASL is done. As you said, it's a nice *extension*. please reply to jrd3@alum.mit.edu, despite the Reply-To address in the header.
Received on Tuesday, 13 April 1999 13:23:19 UTC