On 26.03.2008 09:14, Reinhard Poetz wrote:
What I want to see is a concise pipeline API that comes with only little
overhead in terms of its learning curve and its dependencies on
third-party software. Usually this means that we stick with standard
APIs as much as possible - and I think this rule applies for our
situation too.
See, one thing that I just don't get (and already asked) is how the
pipeline API has anything to do with uri resolving. For me the latter
(using java.net or source resolve) is an implementation detail. Our
current pipeline interface [1] has no relationship to uri resolving. It
only has a reference to SourceValidity because of caching [2].
If all this discussion is about removing this method (and the related
getKeyForEventPipeline()) to get rid of this dependency I'm ok with it.
The caching concern could be implemented in a separate Cacheable
interface which should then also be decoupled from uri resolving (which
seems to point to Peter's approach [3]).
Joerg
[1]
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/pipeline/ProcessingPipeline.html
[2]
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/pipeline/ProcessingPipeline.html#getValidityForEventPipeline()
[3] http://marc.info/?l=xml-cocoon-dev&m=120654005017297&w=4
