It seems that this topic is even more interesting than the environment
abstraction threads we had a while back :)
Ok, first of all, the sourceresolver is a very cool component and I
really like it (and it was also me who started this component years ago
:) ). As the java api lacks such kind of an abstraction, its good to
have it.
Other approaches like the Spring resource stuff are not as good as they
are not very flexible.
So, it doesn't make sense to drop this stuff for Cocoon - seeing Cocoon
as the "big" framework for building web applications.
But on the other side we are talking about making Cocoon more modular
and easier to understand. The Corona work is a great start and for me it
makes totally sense to base the core api just on the java net stuff.
It's much easier to understand and use. When we were doing Cocoon
trainings, it was always a little bit difficult to get the point across
that people should use the source resolver and not the file api or the
java net api. Not a big deal, but still it adds more new stuff on top of
the core api than you might need.
While the source resolver, source factory and source interfaces are of
great use, I'm not so sure about the extensions of the source interface
like modifiable source or traversable source. I rarely needed them
through the years, but your mileage might vary.
Caching is very important and the java api does not provide a very good
way to support caching in general. The source abstaction was built with
caching in mind.
If you look at the pipeline caching we have in cocoon it is rather
complicated (it can cache partial pipelines etc.), and during the years
we switched for a time based/event based caching of complete pipelines.
But again your mileage may vary.
The question is now if we need support for caching in the low level apis
or if it is possible to have a layered approach - which would make the
entry barrier much easier.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
