On 30 Nov 2003, at 22:10, Gianugo Rabellino wrote:
Stefano Mazzocchi wrote: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?
eheh, I have an idea on how to do this nicely.
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;
Very true. In fact, I'm *not* proposing this.
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).
I need *one* implementation and I want to keep concerns separate. What happens next, well, it's not really my problem. If there will only one implementation... well, that's because Darwin didn't need another one... but as long as the architecture allows it, well, it's fine.
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.
See my followup.
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
