RunningModeDependentPipeline (was:RE: New stuff for Cocoon)

[Ard Schrijvers <a....@hippo.nl>]

Hello,

> > 
> http://www.mindquarry.org/repos/mindquarry-jcr/trunk/mindquarr
> y-jcr-source/
> 
> I'd say add it to the cocoon-jcr block but maybe one of the 
> original authors of 
> the jcr block can give some comments.
> 
> > And various components:
> > 
> > - RunningModeDependentPipeline: (Pipeline)
> > 
> > to automatically use different pipelines depending on the 
> running mode, 
> > eg. no caching in dev, full caching in prod, and optionally 
> enabling 
> > profiling with a single system property (I know this is possible by 
> > putting two different xconf/spring bean files under dev/ or 
> prod/, but 
> > this code is quite young in cocoon, so we don't have it 
> available in our 
> > cocoon version)
> > 
> > 
> > http://www.mindquarry.org/repos/mindquarry-webapp/trunk/mindqu
arry-webapp-resources/src/main/java/com/mindquarry/webapp/pipelines/RunningModeDependentPipeline.java 

> hey, I was thinking about something similar just some time ago. I guess this 
> needs further discussions on this list.

IMHO, I really do not like people developing in another mode regarding caching and switch to another caching strategy on production (regarding profiling, ok). I have been trying to persuade everybody to *not* develop against uncaching pipelines, and switch to caching when the project needs to go live. Inefficiencies regarding implementations won't be noticed, untill the project needs to go live, and you end up hacking around to get some performance. I have seen to many projects end up like big slow hacky (hacky to get it performing in the end) projects, which never perform the way they should. By far the best projects around, are the ones that kept performance and caching in mind from the very start, and monitored response times during development against a production mode implementation. 

OTH, why would you ever want a pipeline to be noncaching in development mode and caching in production? If you do everything right, changes in code would also directly work in caching pipelines. Certainly when you use eventcache, it is important to develop in evencaching pipelines, otherwise, you might end up with a production version in which some parts do not invalidate. Finding out the problems later on are much harder. 

So a -1 for me because it would make me having to persuade everybody around me even more, to not develop against a caching strategy that is different in production.

Ard