Steven Dolg wrote:
Joerg Heinicke schrieb:
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
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.
We're arguing that a certain feature is already existing and working,
while talking about a rewrite-experiment that definitely does not have
this feature.
But back to caching:
Caching appears to be incredibly important. Even to the point where "no
caching" means "not acceptable".
On the other hand, when trying to find out what is really necessary and
wanted, there isn't much left. Suddenly it's "just an implementation
detail", "not really important", "makes no difference for the user".
Forgive me for being blunt, but all this appears to me like "I need that
feature. I do not care how it is implemented or how it works. I just
have to have it."
I did not expect this kind of discussion on a dev list. (I even have a
hard time accepting this from a paying customer).
But since it's just a not very important implementation detail, I added
a (simple) caching approach to Corona. (I hope to get a patch ready today)
Perhaps this is all just too abstract and far fetched without any common
basis (iow. code).
Steven,
one of the greatest strengths of community-driven opensource development (I
don't talk about projects like Spring, Eclipse or many other company-driven
projects but about those projects here at the Apache Software Foundation) is the
diversity of the people who participate. At the same time it is also one of its
weaknesses because things need time to grow.
In addition, we people here have different development and language skills and,
don't forget that we both have already had many discussions about what a
reimplementation is about and how we intend to implement this layered design.
I'm happy that people are catching up and participate in the discussion on
different levels. I'm sure that we will become more focused in the future - and
I think that you are right that code will help. At least people will finally
come up with their requirements in more detail ("I need caching" is too
general!) finally so that terms like "layered design" and "caching" become more
conrete.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________
