W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2008

RE: getting WebDAV SEARCH ready for the IESG

From: John Barone <jbarone@xythos.com>
Date: Mon, 4 Aug 2008 09:39:37 -0700
Message-ID: <3877DF108AADAA41976200B6D1D104F4AC64FC@AZEXBACK.bbbb.net>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: <w3c-dist-auth@w3.org>, <www-webdav-dasl@w3.org>

The Xythos server currently doesn't implement the limit feature.  The
server does truncate results based on a server setting.  Making sure the
truncated results are globally ordered is difficult, for the reasons you
outlined and particularly when the search spans multiple data stores.
Implementing the limit feature would pose the same ordering challenges.
I think making 5.17.1 a MUST places a heavy burden on the server


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Monday, August 04, 2008 9:24 AM
To: John Barone
Cc: w3c-dist-auth@w3.org; www-webdav-dasl@w3.org
Subject: Re: getting WebDAV SEARCH ready for the IESG

John Barone wrote:
>> However, it seems to me that the text in 2.3.1 was phrased this way 
>> on
> purpose
>> -- there may be cases where it's not possible to first sort, then 
>> truncate. For instance, when searching can be delegated to an
> underlying
>> SQL store, but ordering can not, how would you implement that? 
>> Thus, I'm hesitant doing any change over here.
> Completely understood.  I'm just saying a client may not want results 
> that aren't ordered over the entire result set.  It might be preferred

> to get no results (and have to further refine the search) than to get 
> truncated results that aren't "globaly" ordered.

I do agree that this may be more useful. I'm just skeptic about making
this change many years after people have written implementations.

>> If you feel strongly about that, we *could* add a statement into the
> "future extensions" appendix.
> I don't feel that strongly about this, just a nice-to-have for some 
> clients.
>> And yes, the inconsistency with 5.17.1 is a bit awkward, but I'm
> really not
>> sure we can change this at this point of time.
> This I think is a bigger deal.  If you acknowledge that some servers 
> cannot (at least easily) order a global result set and then limit the 
> results returned, then how can this be a MUST?  Seems like the same 
> issue to me.

I just checked the document's history, and that particular requirement
was added in 2003, see the thread around
Back then we probably did not realize that we're introducing an
inconsistency between truncation (server enforced) and limiting (on
behalf of the client).

If this is a minor problem, we should just state it somewhere. If it's a
major problem, we could try to fix it. The server I worked on didn't
truncate, so I don't have a strong preference. That being said, it would
be interesting to know how the other servers (Xythos, Catacomb,
Slide...?) behave...

BR, Julian

This email and any attachments may contain confidential and proprietary
information of Xythos that is for the sole use of the intended
recipient.  If you are not the intended recipient, disclosure, copying,
re-distribution or other use of any of this information is strictly
prohibited.  Please immediately notify the sender and delete this
transmission if you received this email in error.
Received on Monday, 4 August 2008 16:59:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:43 UTC