Jason E Bailey wrote > Looking at the API I actually have something similar already written > that uses a resource as a starting point and iterates down through the > child resources to perform the query. > > In that manner it's agnostic as to what's providing the resource, as > long as we are able to obtain the children of a resource.
Right, which is one way of implementing that API. The first thing is to have an API clients can use to query, and the proposed client API is a separate API which can be implemented in any way. > > Since it's possible for the children of a resource to be provided by > multiple resource providers, handing off the queries to be handled by > multiple resource providers may improve the speed of the query. > Additionally, you mentioned each resource provider may optionally cache > the internal results, however you would then still need to consolidate > that set of data and apply ranges and limits, which I don't believe > could be done effectively from within the resource provider itself. I think I didn't mean caching the result, but rather creating the underlying query for the provider (parsing the data objects etc.). > > Alternatively, since I've had the same experience that Steve has had > with iterative searching, an external iteration does not require that > the resource provider do anything more than what it currently does which > is to identify a resource and it's children. > This all depends on how useful/effective you value the search feature of the underlying provider. >From what I understand here, there seem to be cases where that is not efficient and traversing is more efficient. But I wouldn't generalize this and say that for every query a traversal is more efficient. Traversing becomes also more problematic when you want pagination, sorting etc. As said, the client API does not really define how the search is done. So both ways are possible, implementable. But I think, discussing query vs traversal is a great topic for the Oak list as most of the experts are there (and I'm not implying that there are no search experts on this list) Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
