cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Casper" <gcas...@s-und-n.de>
Subject Re: [RT] Converging the repository concept in cocoon
Date Mon, 01 Dec 2003 09:35:11 GMT
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?
> 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;

Yes, you don't necessarily want to access all funtionality through the
Source interface but want to have another access path through the
Repository interface (to be used by the flow layer etc.).
IIUC this is how Stefano want it to be as well.

>
> 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.

I second that.
If we want to have pluggable implementations we need an
abstraction/wrapper of higher level than just reusing what's already
there like the JCR. JCR may be another plug, but IMO not the only one we
are relying on (don't know wether the JCR will be the ideal WebDAV API
;-).
Still some things will always be specific to a particular
implementation. The challenge is to find the right balance.

Guido



Mime
View raw message