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

Kevin Wiggen wrote:

> Ok I am all for simple things, but this whole spec could be considered hard.  We are allowing clients to create ANY type of WHERE clause and append on an ORDER BY, that could be considered hard in itself.  I find it interesting that by simply adding <last-pathsegment> you are now arguing that this is too hard and you want to make it simple.
>  
> I believe the problem is its hard in some implementations.....

Yes, I agree. It depends on how the persistence is organized.

> In mod_dav i believe its probably pretty hard (at least its got to be inefficient) to search for any dead properties.  However 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.

When talking about mod_dav, you need to distinguish between different 
back ends. For instance, the fs backend (the default) doesn't implement 
SEARCH, and if it did it would indeed be hard.

However, other 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.

> I guess I will conceed that in your implementation it is hard to do searching where the <last-pathsegment> is entangled in a WHERE clause with properties on a resouce.  That does not mean that being able to use gt, lt, etc should be left out of the spec.

It *will* be left out of the spec (at least as a mandatory feature), 
unless we can define it in a way where it's likely to be implemented by 
everybody who try to support the latests drafts (such as Catacomb, Slide 
or us).

> Imagine an implementation on mod_dav++ (we will call my new server) where the server had 10,000 items in a directory.  The end user is simply seeing a web page with results from DASL queries sent against the server.  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"  

Actually pagination *is* on the issues list. During the January WG 
meeting, Oracle indicated that they feel this is an absolutely required 
feature.

> I can think of other very simple examples where being able to do searches against last-pathsegments are good things, including order by them.
>  
> I agree that in a world of BINDINGS and others this can get more complex, in fact a lot of things get more complex, but that does not mean I want to take out functionality for the guy who is implementing on top of a file system (ala mod_dav, IIS, and clients like MacOSX and Webfolders).  These guys rely a lot on filename.  Whether I like it or not (I HATE our reliance on file systems and how they are laid out, and how we find info btw) this is how these systems operate.  I don't think we (the people with better systems) should be taking away fucntionality from the little guy (I always wanted to call MS the little guy).

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 guess I am confused on why it is easy for you to allow complex queries against properties and not path segments.  As I said in my last note, I am OK with not making the path segment part of the where clause (although I think it is powerful and useful) but I am NOT ok with taking away the power of a where clause for last segment (ie gt, lt, not, or, and, etc).  

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

> I could create a system that allows BIND and the last-pathsegment exists in the where clause.  In your mind is this impossible to build?  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?

It's a separate process. As it is a separate process, it will make 
ordering and result truncation harder (because you can't let the 
database do that anymore).

> I'll leave order by alone for this note as I want to understand where we are going to place path segment in DASL first.
> 
> BTW I thought the open issue we were resolving is how to handle last-path segment.  I am not trying to be difficult or bring up new issues, I am simply trying to close this issue with you.  :)

Understood.


Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 19 November 2003 06:35:39 UTC