Gianugo Rabellino wrote:
Rolf Kulemann wrote:
Hello,
I set up a small cocoon app which uses the Repository interface. I'm now up to a point where would use a kind of property query in order to receive all resources/paths matching the query.
Currently the repository does not support a property "search" method.
IMHO this is an important feature and should be a concern of the RepositoryPropertyHelper.
Another question is, what kind of queroes should be supported? DASL queries???
Oh, queries... well, I really appreciate your enthousiasm, but my advice is not even dare to think that querying is going to be solved just by an email thread. JSR170 people have been fighting over it quite a while, and overall searching is _really_ a PITA.
Besides, DASL isn't really a query language but rather a query wrapper: you're free to insert whatever query language you want (DAV:basicsearch being the most prominent one) inside DASL (which boils also to an HTTP method + a bunch of headers).
Consider also that it's not just the query language, but even how results are reported.
MHO? I really feel uncomfortable with the repository abstraction as a whole since, after all, it has to be somehow modeled into webdav. I'm fine with it as long as it's lightweight enough, but for more serious needs I'd much rather wait for JSR170 to come out.
Hmm, I'm also looking forward to JSR170. Don't you think there is place for wrappers/abstractions of higher level (better mapping to Cocoon concepts)?
I think so, yes, but with the notable exception of searching. I really don't see how you can come out with a searching "Uber-API" able to rule all possible repository implementations (WebDAV will use DASL, JSR170 has two possible - and both optional - impls, a RDBMS store will have plain SQL: a hell of a mess). So I see only two ways out:
1. rule out searching altogether;
2. provide pitiful hooks such as
Result query(Query)
where Result and Query are interfaces to be implemented by every repository. Which means that you can't interchange Result and Query from different implementations. Which means that you can't exchange _query languages_ at all. Which means, in the end, a useless API.
I think/hope the repository is not modeled after WebDAV-only and may account for JSR170 as well.
However it shouldn't be modeled after JSR170-only either (in which case you would be better off just dropping in the JSR170impl.jar) as the major point is to be simple to use from the flow layer and based around some higher level concepts such as (XML?) documents.
+1, for now (see below).
If JSR170 becomes Cocoon's one and only interface to repositories (of all sizes and needs) then this particular component may be mostly redundant as having a portability layer becomes pointless.
Well, you have also to consider that JSR170's goal is to become the one and only interface to repositories of all size and needs, so I do expect, in the end, that this particular component can be superseded. But it depends, for now, from a large number of things to happen. Too many to rule out the abstraction right not.
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
