Subject: Re: Partial equality match and sort order

From: [email-masked]
Date: Wed, 12 Mar 2003 17:36:28 -0500

ONe of the best ways I know to shake out bugs and fruit from a tree is to
ask for a Last call.  And, for the first time in a long time, we seem to
have concensus on something.  Be still my heart.  I am now hearing 4 people
say removing sorting to the client and out of the CS is a good thing.
Sorry, Doug, but that does indeed stand as concensus and not even rough.
Now, that being said, is this hard to do and does it break something else.
If so, maybe we can get some help from those who are arguing to have it
removed.  5 pair of eyes looking at the draft to remove this would really
help  a lot. 8-)
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

                      Patrice Lapierre                                                                                                     
                      <patrice.lapierre@ora        To:       [email-masked]                                                         
                      cle.com>                     cc:                                                                                     
                      Sent by:                     Subject:  Re: Partial equality match and sort order                                     
                      owner-ietf-calendar@m                                                                                                
                      ail.imc.org                                                                                                          

                      03/12/03 04:51 PM                                                                                                    

On Tue, 2003-03-11 at 15:08, [email-masked] wrote:
>
> Make that 3 votes for sorting in the client rather than in the CS.
> (If my MUA can insertion sort mail that arrives out of order in my
> Inbox, why cant my CUA?)
>

Make that 4 votes.

Interested parties can look at the archive:

http://www.imc.org/ietf-calendar/mail-archive/msg03435.html

--
Patrice.

---

From: [email-masked]
Date: Wed, 12 Mar 2003 20:13:07 -0500

hm, the plot thickens.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

                      sfg                                                                                                                  
                      <[email-masked]>           To:       [email-masked]                                                         
                      Sent by:                     cc:                                                                                     
                      owner-ietf-calendar@m        Subject:  Re: Partial equality match and sort order                                     
                      ail.imc.org                                                                                                          

                      03/12/03 06:20 PM                                                                                                    

> > (If my MUA can insertion sort mail that arrives out of order in my

I vote against this.

I've read the archives, I'm mainly a lurker with desires to build an
Open Source CAP Server (http://www.sf.net/projects/jical)

I would have thought ordering was a natural requirement of a server vs a
client. Surely your data store can make these things easier via indexes
etc. The comparison to an Inbox doesn't stack up. From reading the spec
- CAP Servers are more like a specialised RDBMS. Imagine if your RDBMS
did not support ORDER BY? An alternative would be to add the ORDERBY to
capabilities so that the client can query and see if the server can/will
handle ORDERBY.

Stuart Guthrie
vcard:   http://www.eurekait.com/sfg.vcf
OSS:     http://www.sf.net/projects/jical

---

From: [email-masked]
Date: Fri, 14 Mar 2003 12:06:26 -0500

Doug replied on 03/11/2003 10:10:15 AM MST:
> > I big time object.  This just makes the CS have to cache up ALL 
matching 
> > objects/values to return before it can return ANY so that it can sort 
> > them based on some implyed sort order (the order of the SELECT).  This 

> > makes bounded latency even worse!
> 
> What do you do with the other items that must be sorted that is
> any different?

Sorting is a client side preference/consideration to me. 

Each CUA can sort and resort the results any way the like, kinda like the 
way a good MUA will sort messages by Sender, Subject, Date, etc.  Does my 
mail server have to worry about how I want to sort or resort my data?  No. 
 Does my mail server know my locale settings so that it can sort the 
results accurately?  No.  Does my mail server resort 'new arrivals' 
recieved out of order so that it can render properly in my Inbox.  No, my 
MUA does that too.  The same logic applys to CUAs.

Making the CS sort the results means that the entire set must first be 
gathered THEN sorted THEN returned.  If the CS is going to have to send 
back all the results anyway (assuming I dont ABORT it because its taking 
too long) why not let the CUA do the sorting so that the CS is available 
for other things/users?

Any decent CUA is going to be able to sort / resort data for the CU so why 
not allow it to do the sorting entirely?  That would allow the CS to start 
returning results as soon as it starts to get them rather than having to 
cache them ALL. 

In addition, making a CS store and then sort the results instead of 
returning them immediately will not likely scale well to large user 
counts.  If the set of returned results will be the same no matter if the 
CS sorts them or the CUA sorts them but we get better scalability by 
letting the CUA sort them then what benefit do we get by making a CS do 
the work?

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...