Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <47EA45FC.4090407@dslextreme.com>
Date: Wed, 26 Mar 2008 05:47:56 -0700
From: Ralph Goers <Ralph.Goers@dslextreme.com>
Reply-To: rgoers@apache.org
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: JNet integration
References: <47E509B2.7050003@tuffmail.com> <47E50A75.8090001@apache.org>
 <47E51B61.2050701@tuffmail.com> <47E7F20D.3020308@tuffmail.com>
 <47E8A7CE.6040508@apache.org> <47E9061C.5030105@tuffmail.com>
 <47E911D9.9040503@apache.org> <47E9B1CA.6050202@gmx.de>
 <47E9FC91.3080004@apache.org> <47EA37F4.3000206@gmx.de>
 <47EA3BB0.5090303@apache.org>
In-Reply-To: <47EA3BB0.5090303@apache.org>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit


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.

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.

Ralph