cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Converging the repository concept in cocoon
Date Tue, 02 Dec 2003 16:37:28 GMT

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
>> interface and a few implementations that I can choose when I install 
>> cocoon. This implementation would also implement 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.


View raw message