RE: discovery of search arbiters, was: Comments on search-00 draf t

In the current implementation of the SEARCH prototype in slide any existing
resource within the server's namespace may act as an arbiter.

So a call 
RequestUri= http://localhost/mySEARCHEnabledServer
scope =    /collection1/collection2

should be equal to 
RequestUri= http://localhost/mySEARCHEnabledServer/collection1
scope =    /collection2

I don't see a reason to restrict it either to first example (arbiter should
be the "root" of a repository) or second (each collection within a
SEARCHable repository must be able to act as arbiter). Within slide's
implementation I don't see, if one of the two alternatives could be
implemented more effectively.

Regards,
Martin

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Freitag, 29. März 2002 14:54
To: Lisa Dusseault; www-webdav-dasl@w3.org
Subject: discovery of search arbiters, was: Comments on search-00 draft


> 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 Tuesday, 2 April 2002 07:48:41 UTC