Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <47E91604.5050009@apache.org>
Date: Tue, 25 Mar 2008 16:11:00 +0100
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de;
 rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
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>
In-Reply-To: <47E911D9.9040503@apache.org>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

Reinhard Poetz wrote:
> 
> 
> Once again, my goal is that if you use e.g. Corona in its simplest form, 
> I don't want to make everybody and his dog depend on 
> JNet/SourceResolve/Source. E.g. see the FileGenerator. Using the URL 
> object is enough for simple use cases of a pipeline API.
> 
> Yes, I understand that when it comes to caching pipelines, you need 
> more, but not everybody needs caching pipelines. For that purpose there 
> could be a CacheableFileGenerator, etc.
> 
> If you are right and it is difficult or even impossible to remove the 
> dependencies on source/sourceresolve/xmlutils/jnet, then be it. I 
> withdraw my example Url("servlet:...") from above. When we can switch to 
> sourceresolve 3.0, the dependency graph will get smaller anyway.
> 
> The main benefit from using URLs (instead of the SourceResolver) comes 
> from simple use cases, e.g. you need a pipeline in your Java application 
> that reads in some XML file, performs some transformations and finally 
> creates a PDF document. FWIW, using URLs should be all that you need.
> 
I totally agree with Reinhard; for most uses cases getting an input 
stream (or sax events) via a url is totally sufficient. With the source 
interface we created another abstraction like the request/response 
abstraction in the cocoon environment which seems to be nice and great 
but in the end is not really needed, creates problems in other places etc.
Let's forget jnet for a second and see if the java net api can be 
sufficient. The only other use case might really be caching. You need a 
way to find out if a resource might have changed or not, but I think 
that should be possible.
Using java net api for Corona makes totally sense to me; it keeps it 
simple and small.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org