Re: SEARCH by last path segment, Was: SEARCH for displayname

Julian Reschke wrote:
> Kevin Wiggen wrote:
>> [...] it would probably be easy for mod_dav to allow a client to use 
>> <last-pathsegment> in a where clause and also allow an order by.
> 
> [...]  backends such as Catacomb (Elias?) and subversion use
> databases as backends. In Catacomb, there's a global property table, so 
> implementing SEARCH would be straighforward.

Realize that implementing <last-pathsegment> for mod_dav_fs would 
literally entail searching the _entire_ namespace addressed by the 
search arbiter. While not hard, this is demonstrably and unacceptably 
inefficient (i.e. do not expect this to be implemented for mod_dav_fs 
anytime soon, if at all), whether the feature appears in the WHERE 
clause or the ORDERBY clause.

Implementing this feature for Catacomb, however, would be fairly 
straightforward as one can leverage the provided SQL language features 
for pattern matching. The semantics of translating the include/exclude 
directives into the underlying SQL query could be problematic if not 
defined well...

I believe that this feature would be rather difficult to implement for 
Subversion (especially considering the case of versioned collections).

>> [...] As DASL has no pagination (or however that is spelled), I 
>> want to issue a search and create my own pagination.  Thus I issue the 
>> first search and order by the <last-pathsegment>.  The search gets 
>> truncated due to the server only allowing 100 items to be returned via 
>> a DASL query.  My client can now turn around and issue a <gt> last 
>> value i got </gt> and get the next "page"

This use case can be addressed using displayname and, as such, does not 
provide a sufficiently compelling argument for including the feature in 
the specification...

> The issue here is that unless you make a feature mandatory, a client 
> will be able to handle the case where it doesn't exist anyway. 
> Therefore, it's good to have a minimal number of optional features.

I would go so far as to say that clients MUST handle the cases where 
optional features are not supported by a given server.

> It's not complicated per se, but the question is whether it's needed. 
> Please suggest a few use cases.

+1 - I have not seen any scenarios that cannot be handled adequately 
with displayname and judicious use of the DAV:like operator. Granted, 
DAV:like is optional, but it has been suggested that the last path 
segment stuff be optional as well...?

>> [...] From what I know of what you want to do, you find all the 
>> resources that match the where clause and then go looking for the ones 
>> that map to the scope.  Why is searching your scope with a where like 
>> clause harder than searching properties?

Actually, it is generally more efficient to take the opposite approach - 
limit your search by scope first, then identify resources which satisfy 
the WHERE clause. Perhaps this serves to address your question? By 
putting path segment constraints in the WHERE clause of a DASL request 
you are essentially mixing in the semantics of the SCOPE clause, thus 
requiring some 'special casing' in the processing of the request...


Cheers,
Elias

Received on Thursday, 20 November 2003 05:43:33 UTC