W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > January to March 2002

discovery of search arbiters, was: Comments on search-00 draft

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 29 Mar 2002 14:54:03 +0100
To: "Lisa Dusseault" <ldusseault@xythos.com>, <www-webdav-dasl@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCCEPCEEAA.julian.reschke@gmx.de>
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Thursday, March 28, 2002 7:42 PM
> To: julian.reschke@greenbytes.de; www-webdav-dasl@w3.org
> Subject: Comments on search-00 draft
> ..
> g) Comment on how clients find search arbiters
> I understand we probably don't want to specify what the search
> arbiters must
> be in the general SEARCH case.  For some special kinds of searches, search
> arbiters could be very limited or completely unlimited.
> However, it would enhance interoperability to specify for DAV:basicsearch
> that all collections on a DAV server supporting basicsearch
> SHOULD be search
> arbiters, effectively performing a search for the content within that
> collection.  This would make it easy for clients to figure out what search

I don't think this can be guaranteed. You could have a search arbiter on
server a which offers DAV:basicsearch for any resource of server b, without
server b being aware of that.

> arbiter to send the SEARCH request to for any given scope.  However, the
> specification would have to explain what relationship the scope has to the
> Request-URI, and what the server should do if they are different (e.g. use
> the scope specified in the body preferentially if it can be handled).

The draft currently says that a) the scope element is mandatory and b) that
the search scope is defined by the scope element. Do you think this should
be changed to allow "default" scope (being the request URI)?

> An alternative is that the draft could specify that the search arbiter for
> DAV:basicsearch SHOULD be a "root" of a repository. The client
> would have to
> be able to discover the "root" but that's not too hard -- for any
> collection
> that the client wants to search, send an OPTIONS request to that
> collection,
> then to the parent, recursing up the namespace until it either reaches the
> root ("/") or stopping at some parent that does not indicate
> SEARCH support
> in OPTIONS response (e.g. http://java-based-dav-server.com/servlet).

Again, in the general case we can't guarantee that for a given resource
there actually *is* a search arbiter offering DAV:basicsearch. Even if there
is one, it itself may  be on a different server (or the same server and a
different port).

> Third alternative: for any collection that can be searched with
> DAV:basicsearch, include a "DAV:search-arbiter" property that contains a
> DAV:href element, containing the URL that MUST be used by the
> client as the
> Request-URI for a SEARCH method that names that collection in its scope.

In the general case, how would a collection "know" that it can be searched?

However, AFAIK in *current* implementations *each* WebDAV research can act
as a SEARCH arbiter. In which case the discovery is trivial (just look at
DAV:supported-search-grammar or DAV:supported-method-set).
Received on Friday, 29 March 2002 08:54:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:42 UTC