Re: next steps / open issues in DASL framework

Good evening,

    Just here to weigh in on the following... Thanks again, Julian, for 
driving the open issues to resolution.

Julian Reschke wrote:

>JW3:
><http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.htm
>l#rfc.issue.JW3>
>
>ejw@ics.uci.edu 1999-04-26 This specification essentially defines a new type
>of Web resource, of type "search arbiter". This raises a number of questions
>regarding how this kind of resource interacts with existing HTTP methods. I
>would expect to see a section which goes through and details the
>interactions between HTTP and WebDAV methods and search arbiters. For
>example, it seems reasonable to me to allow a search arbiter to potentially
>reply to GET (perhaps with a human-meaningful description of the
>capabilities of the arbiter), and for this GET response to potentially be
>authorable using PUT, and locked using LOCK. However, I wouldn't expect
>COPY, MOVE, or DELETE to work, although I would expect PROPPATCH and
>PROPFIND to work OK. Another issue is what kind of resource type a search
>arbiter returns in the resourcetype property (I'd expect a <searcharbiter/>
>element).
>
>ejw@ics.uci.edu 1999-04-26 How does a search arbiter respond to searches, if
>the search arbiter URI is within a search scope? The answer to this is
>related to the answer to whether a search arbiter has its own properties,
>body, etc.
>
>--> I think there is an agreement that the SEARCH arbiter isn't a special
>resource type (except for it's ability to respond to search messages). Do we
>have agreement on this? Does the spec need to be clarified somewhere?
>
<Elias>
    I think we should add something to the spec to clarify the issue. 
While I generally agree that a searcharbiter isn't a 'special' resource 
type I think there may be sufficient confusion on this in the future to 
warrant a more explicit treatment of the subject.
</Elias>

>JW9:
><http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.htm
>l#rfc.issue.JW9>
>
>ejw@ics.uci.edu 1999-04-26 How does a DAV client discover which search
>arbiter can be used to search a portion of the DAV namespace? At present,
>the specification seems to imply two things (a) that "/" might be a typical
>arbiter, and (b) that other arbiters can exist and you can get redirected to
>them. If this issue isn't addressed in the specification, it might lead to
>clients having hard-coded search arbiter locations, thus forcing servers to
>put an arbiter at those locations or be non-interoperable. Or, it will
>require clients to be configured with the search arbiter location, which
>also seems bad. It seems far better to have a predefined mechanism which
>clients can use to discover the location of the search arbiter. One simple
>mechanism would be to define a property on each collection (but not each
>resource) which gives the location(s) of appropriate arbiters.
>
>--> I currently can't think of an easy method for the general case (in which
>a resource doesn't have any knowledge about the SEARCH arbiter resources
>that could search it). So, I'd say it's out of scope. Should the spec say
>anything about this problem?
>
<Elias>
    I'm in agreement with Jim on this one. Currently with mod_dav you 
can turn on DAV support for a subset of the namespace, and the same will 
almost certainly be true with some DASL implementations. (If not by the 
same 'DAV On' or 'DASL On' mechanism, then via 'limit' style directives, 
access controls, etc.) It makes sense for the root of a DAV 
server/namespace to be a default location for a searcharbiter or a 
redirect to the location of the searcharbiter for the server/namespace, 
but I don't think it can be enforced. Maybe this should be a 'SHOULD 
provide' requirement of the spec? At the least, the spec. should say 
something about it.
    The suggestion to define a property on collections that are 
searchable seems like a possible way to allow searcharbiter discovery. 
This would address arbiter discovery and redirection issues, but raises 
a couple others. Specifically, should the property be live or dead? The 
use cases involving moving a resource from one namespace to another that 
is searched by a different arbiter or from a DASL aware namespace to a 
non-DASL aware namespace (and vice-versa) would indicate that the 
property should be live. On the other hand, if a dead property were used 
it would allow one to specify different searcharbiters for different 
resources.
    The example of a non-DAV service, such as Google, that is DASL aware 
is a compelling one. I think it is likely that DASL gateway search 
services like this will become common and should be considered seriously 
in this discussion.
</Elias>

>The last one:
>
>JW5:
><http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.htm
>l#rfc.issue.JW5>
>
>ejw@ics.uci.edu 1999-04-26 On the topic of partial search results, DASL
>currently has no way for a client to request the next chunk of a set of
>search results. Since *every* search service I've interacted with on the
>Internet has a feature for returning the next set of search results, I
>really would expect this feature to be in DASL. An explanation for why this
>feature isn't present should be in the protocol specification if it is not
>going to be supported.
>
>--> My position is "out-of-scope", because nobody seems to have asked for
>this feature since it was raised. But I'm also willing to propose an
>extension to DAV:basicsearch that would allow it. Feedback?
>
<Elias>
    I've been a little busy with our DASL implementation work to raise 
the issue, but it has been on my mind. I think this is an issue that 
needs to be thought out a little more. As Jim states, end users will 
expect this functionality. By not allowing people to get the next set of 
results, the protocol is cutting them off from some of the results of 
their query. If they don't know what has been left out, they won't 
necessarily know how to get it by modifying their query, and hence the 
information is much less accessible to them - possibly entirely 
unavailable. This is not how I would want a searcharbiter to mediate my 
query for me. Adding an element to the limit part of the request seems 
like a reasonable approach to me. If servers don't want to cache results 
for a minute or so, then they can recompute the results for me. Either 
approach is valid, and should be left to the specific implementation.
</Elias>

Received on Tuesday, 12 March 2002 00:38:18 UTC