cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [Plan] The future of Cocoon
Date Thu, 27 May 2004 14:36:18 GMT
Ah, btw, I added all points to a new document under planning/roadmap.xml.
So, feel free to update that doc as well.

Carsten 

> -----Original Message-----
> From: Sylvain Wallez [mailto:sylvain@apache.org] 
> Sent: Thursday, May 27, 2004 4:25 PM
> To: dev@cocoon.apache.org
> Subject: Re: [Plan] The future of Cocoon
> 
> Ugo Cei wrote:
> 
> > Il giorno 26/mag/04, alle 11:17, Carsten Ziegeler ha scritto:
> >
> >> Some things that come to my mind for 2.2:
> >> - first finished version of CForms.
> >> - deprecate XSP (and provide a viable alternative)
> >> - cleaning up the caching/store mess
> >> - remove deprecated blocks etc.
> >
> >
> > - Differentiate between blocks that provide a service to 
> other blocks 
> > and blocks that contain just samples or small applications 
> built upon 
> > cocoon (petstore, tour, linotpye). Maybe "samples-only" 
> blocks should 
> > be a separate download.
> 
> 
> +1
> 
> > -Deprecate blocks that haven't been maintained in a long while or 
> > don't serve any evident purpose. Web3, apples, python, php, 
> asciiart 
> > come to mind. Maybe I'm wrong about some of them but I just want to 
> > make a point, we can then decide on a case-by-case basis.
> 
> 
> +1
> 
> > - Review the implications and the implementation of pooling.
> 
> 
> A big +1.
> 
> > - Reduce unneeded dependencies on Avalon, where possible.
> 
> 
> +1. Stated differently: introduce constructor and property dependency
> injection.
> 
> > - Review the logging framework. Log4j is the de-facto 
> standard and we 
> > have blocks that complain if Log4j is not properly configured, so 
> > let's accept it and stop reinventing the wheel.
> 
> 
> See my answer to Carsten.
> 
> > - Drop that Excalibur datasource. Components that need a DS 
> should get 
> > one provided by the container via JNDI. If we don't have a 
> container 
> > (running via the CLI, for instance), let the environment 
> provide one 
> > and bind it to a JNDI namespace.
> 
> 
> Mmmhh... defining the JNDI datasources is container-specific, and 
> therefore makes the applications not self-contained. Furthermore, 
> subsitemaps (and blocks in the future) can come with their own 
> datasources used locally. I'm not sure this is compatible with the 
> global declaration induced by JNDI.
> 
> > - Write more tests (you knew this one was coming ;-) ).
> 
> 
> Don't we have enough of them? :-P
> 
> Sylvain
> 
> -- 
> Sylvain Wallez                                  Anyware Technologies
> http://www.apache.org/~sylvain           http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
> 
> 


Mime
View raw message