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
