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

Martin,

while I agree with the rest, I think you've got a mistake in resolving the
relative URIs:

> RequestUri= http://localhost/mySEARCHEnabledServer
> scope =    /collection1/collection2

-> actual scope is http://localhost/collection1/collection2

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

-> actual scope is http://localhost/collection2

> -----Original Message-----
> From: Wallmer, Martin [mailto:Martin.Wallmer@softwareag.com]
> Sent: Tuesday, April 02, 2002 2:48 PM
> To: 'Julian Reschke'; Lisa Dusseault; www-webdav-dasl@w3.org
> Subject: RE: discovery of search arbiters, was: Comments on search-00
> draft
>
>
> 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:59:36 UTC