I think a much better approach would be to come up with a
Repository.java
interface and a few implementations that I can choose when I install cocoon. This implementation would also implement Source.java and provide its functionality thru a URL protocol.
This allows:
- clear separation of concerns: cocoon should *NOT* be doing repository stuff, which is already big and complex enough
- complete IoC: you choose the implementation and the implementation decides what to do and how to do it. Your contract remains the same (thru the source-provided URL protocol and thru the component interface)
- transparent polymorphism: you can have different implementations of a repository... file system, webdav, CVS, JCR, ... without having to change any code in your application
Thoughts?
A couple:
1. How do you plan to deal with a Source (which becomes a URL in the end) with complex stuff such as versioning or, even worse, searching? I'm afraid we'll come up with a very ugly URL design, I can't really think of a way to express searches in a URL, where a search has at least four parameters (what, scope, conditions, ordering) without resorting to URL parameters wich are IMO very bad;
2. Though I'd just _love_ to see it happen, I'm afraid that it will be practically impossible to have different, pluggable, implementations. I cannot think, apart from JCR and WebDAV, of a repository implemented on top of other stuff without hacks or heavy implementation (metadata, searching and versioning are all hard stuff to do).
Note: I'm definitely +1 on having one standardized approach to the repository issue. I'm just not that sure that we can really make it with what we have today without mimicking the JCR API, which could be suboptimal.
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
