cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: JNet integration
Date Wed, 26 Mar 2008 12:57:49 GMT
Ralph Goers wrote:
> Carsten Ziegeler wrote:
>> Hmm, I don't think so. Imagine a pipeline java api just taking a uri 
>> for the sources used in the pipeline. That's simple and easy.
>> Now, you can use the source resolver on top of that, resolve your 
>> sources and you get a uri from your source that you can put into the 
>> pipeline api.
>> That's neither a mess nor does it require more java coding.
> That sounds good in theory, but the proof is in when you actually try to 
> do it with caching enabled. As I said, I'm not really too interested in 
> the non-caching use case as I view that as the minority use case. 
> Furthermore, the non-caching use case can always be dealt with by using 
> the caching use case and just turning off the cache.
:) Sure, I have many use cases for pipelines where I don't need caching 
at all - like some processing pipelines that are not used for creating 
web responses.

> So you build this pipeline API that only uses Now you want to 
> build pipelines that cache. Does the Source now have to show through the 
> caching version of the pipeline API?  If it does you will have a real 
> mess as now users of pipelines have to determine whether they are 
> caching or non-caching just to determine what methods they can use.
Hmm, ok, I have not thought about this very deeply, so I don't have an 
answer yet and perhaps there is no good answer and it might turn out 
that all this is not a good idea.

But :) without looking further into it, I have the feeling that it 
should be possible to build a clean layered architecture that solves all 
our problems. And perhaps it turns out that it might make more sense to 
use the sourceresolver throughout all of these layers.

Carsten Ziegeler

View raw message