cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Layered software designs
Date Thu, 27 Mar 2008 07:01:11 GMT
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        reinhard@apache.org
_________________________________________________________________________

Mime
View raw message