I think you are out of your mind. (Not seriously).
I have to tell you, Cocoon without caching pipelines would suck so bad
with performance problems you would give it the boot in very short
order. Even without "Cocoon", as soon as you start doing anything
serious caching will become necessary.
I'll give you a trivial example. I wrote my own I18n implementation for
use with JSF and used Excalibur Source to read an XML properties file
containing the keys and values. The first implementation checked to see
if the file was valid for every key that was read. This didn't perform
well at all and I changed my Validity so that the file validity was only
checked once per Request. This made it so the overhead of this utility
was not noticeable. Now imagine that instead of just checking the
validity I had been actually reading the file for every key!
Ralph
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.
