Carsten Ziegeler wrote:
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.
Does it? It seems to me the URLConnection class provides the same level
of abstraction and functionnality than a Source.
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.
Hmm... If this is just about Source.getSourceValidity which is
optionally implemented (non-caching source can simply return null), we
could equally well have a CachableURLConnection.
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.
The main need for the Source abstraction was to circumvent the
staticness of URLStreamHandlerFactory. Otherwise, pretty much everything
we need is there:
- extensible framework for cacheable, modifiable, traversable,
whatever-able sources with URLConnection sub-classes,
- integrated parsing/conversion features with the getContent() method
- source-resolving using the URL(URL context, String spec) constructor
The staticness problems of URLStreamHandlerFactory are still there in
the JVM, but the OSGi/Equinox guys have found creative ways to
circumvent them on most JVMs. If we're happy with this solution, it
seems to me the Source abstraction is one of the many "cocoon-isms" we
should consider to gently deprecate just as the copy of the servlets
that we have in our environment abstraction.
Fewer new concepts to learn for newcomers, fewer specific concepts that
hinder the integration of Cocoon with other environments.
My 0.02 euros (which are worth their $ these days!)
Sylvain
--
Sylvain Wallez - http://bluxte.net
