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.
