cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
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 java.net. 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
-- 
Carsten Ziegeler
cziegeler@apache.org

Mime
View raw message