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.
FYI, ETA for the reference implementation of JSR170 (aka JCR) in slide/proposals/jcrri is 2/4 weeks.
The current state of affairs is that JCR will support two query languages: a SQL-like called JCRQL and a sub/superset of XPath. Both are optional, and a container has to include at least one of them to be compliant.
Now, don't shoot the pianist.
This is what the group came out with, not what I personally like.
The idea is to fix problems with the spec in the reference implementation ;-)
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
