cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: JNet integration
Date Tue, 25 Mar 2008 17:10:31 GMT
Carsten Ziegeler pisze:
> 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.

I agree that our Environment abstraction was awkward - it introduced abstraction that never
was a
real abstraction and mostly duplicated existing, quite nice servlet API.

At least now I fail to see coherent, nice to use standard Java API that Excalibur's Source
and
SourceFactory duplicates. As for now I can only see obstacles like:

  new URL("blabla/foo");

will fail with java.net.MalformedURLException: no protocol: blabla/foo
so one must use:

  new URL(baseURL, "blabla/foo");

Who will judge if given path is relative and requires baseURL instance? How one will get this
baseURL instance?

Guys, it's non-sense...

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

Yep, the idea sounds great - that's why I started to dig into JNet. As usual, the devil is
in a detail.

-- 
Grzegorz

Mime
View raw message