On 27.03.2008 02:25, Steven Dolg 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]).
Just as a general observation:
I'm starting to believe that I do not understand (anymore) what this is
all about.
We're jumping from high-level concepts ("caching", "layering") straight
down to the lowest level ("it's just method a in class B") and then
right back.
I have had the same problem from the beginning [1] and expressed it in
my question above again. What is this discussion about - if uri
resolving has nothing to do with the pipeline API? And what do we win
when replacing source resolve with java.net except that we have one less
dependency - when nobody really gets in contact with uri resolving
anyway? I have only received half an answer to only the second question
(standard API). Only then I started to look at the relationship between
uri resolving and pipeline API and found only this one reference to the
source resolve package.
Joerg
[1] http://marc.info/?l=xml-cocoon-dev&m=120649777119480&w=4
