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.
Ross
