cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject [Vision] Knowing When We are Done
Date Tue, 06 Dec 2005 17:29:51 GMT
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.


Mime
View raw message