cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Vision] Knowing When We are Done
Date Wed, 07 Dec 2005 07:36:02 GMT
Berin Loritsch wrote:
> In all the talks of redesign or not, there has been a recurring 
> question as to the vision.  Sylvain has outlined some things that he 
> would like to see, but they really don't constitute a vision.  They 
> are a nice list of improvements, but they aren't a vision.  In my 
> experience the best visions really don't have to do with features and 
> improvements, but with what we expect to be able to do with Cocoon.  
> We need to be able to put our vision statement in one or two 
> paragraphs, and it needs to convey a little more than technology.  
> Visions contain emotional content as well.
> There are two kinds of visions.  One is the kind that you use to 
> attract users, "Oh, that's what I need and they approach things the 
> way I expect".  That's the kind that ends up on the front page.  Then 
> there's the kind of vision that explains how you think something 
> should be done.  Kind of like a how-to that describes what _should_ be 
> instead of what is the case.  It has to be something exciting, 
> something that people can get behind.
> Now, whether we are talking about evolutionary change or revolutionary 
> change, we need to have a common vision.  How else will we ensure the 
> transition goes as smoothly as possible?  Good foundational principles 
> of modern software development are just side issues.  Let's take a 
> look at what we want Cocoon to be.  Below is my vision, which I hope 
> starts discussion.  We can start consolditing the common points once 
> people post their visions.  Let's gather the information, and then see 
> if we can look at some commonalities and think a little outside the 
> box to make as many of us happy as is practical.
> ----------------
> Berin's Vision
> ----------------
> I envision a Cocoon which takes its principle strengths in separation 
> of concerns to make developing web applications easier.  Modern web 
> applications provide machine-to-machine communications via web 
> services and email as well as various views into the data.  I envision 
> a Cocoon that makes Java look attractive again, proving that it is 
> suited for the rapidly changing web environment.  I envision a Cocoon 
> which avoids configuration where it is unnecessary, and instead 
> employs easy to understand conventions.  I envision a Cocon that is 
> able to be extended using standard Java mechanisms such as the JAR 
> services approach.  I envision a Cocoon where I only have to learn 
> Java and XML to be affective.  I see a Cocoon where testing is 
> embraced, encouraged, and made easy.  I see a Cocoon where any 
> errors/exceptions tell me exactly where the problem lies, down to the 
> source code line--even if that source is not Java code.  I see a 
> Cocoon where the Sitemap is not the preferred way to map URLs to 
> generating content.  I see a cocoon where convention dictates the 
> pipeline.
> A note about blocks:  while they *can* be helpful, they are not 
> central to my vision.  I am open to them, and if they are a part of 
> Cocoon's future then the following applies: "I see a cocoon where 
> communities can share solutions packaged up in blocks to be reused in 
> other applications".  I'm thinking solutions like user authentication, 
> portal support, or other generic solutions.
> -------------------------
> That's my vision.  What's yours?  How much overlap is there?  Let's 
> start this discussion, I think we will be pleasantly surprised how 
> close many of us are with where we want Cocoon to go.

Oh yes, we are close.

To all the above, add the following: I envision a Cocoon where I can use 
the power of the pipeline engine in almost every environment where there 
is some XML data to be processed. I envision a Cocoon where people can 
use a single unified scripting language for both the client and the 
server. I envision a Cocoon where the expression used to access a given 
data is the same everywhere. I envision a Cocoon where any change to a 
source file, even Java, is instantly reflected in my application.


Sylvain Wallez                        Anyware Technologies           
Apache Software Foundation Member     Research & Technology Director

View raw message