cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [Vision] Knowing When We are Done
Date Wed, 07 Dec 2005 08:10:20 GMT
Sylvain Wallez wrote:
> 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.

Whilst I agree with everything above I feel they are too focused on the 
developer side of things. Here are a couple of additions from the 
perspective of the end user:

I envision a transparent integration of remote resources. I envision a 
transparent integration of dynamic and static resources. I envision 
being able to build a Cocoon application by saying "given these input 
types, I want this output type" and to have the resulting application 
automatically tested against my test inputs.


View raw message