Berin:
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.
Sylvain:
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.
Ross:
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.
Torsten:
Plus I envision to have good testcase coverage for the whole system. I
envision to have a clean core that shines through simplicity. I
envision a non-viral component handling (One word: AbstractLogEnabled).
POJOs and factories where feasible. I envision being able to drop block
jar into a folder and extend my cocoon's functionality without
configuring or doing anything else. (Maybe even at runtime.) I envision
a cocoon where flow is not a 2nd class citizen. I envision a cocoon
where your components like caches might persist. I envision log
messages that are also understandable when you are not a core
developer. I envision a cocoon where you have to write less.
Vadim:
I envision Cocoon where components configurations are consistent (and easy to
guess), with sensible defaults. I envision good set of test cases running
nightly which flag any regressions early and those regressions are resolved.
Solid core with clean interfaces between layers (pipeline engine - sitemap
machinery - entry points/environments). Easy to read and maintain core
implementation. Single expression language throughout with unified object model.
Solidifying existing functionality is prioritized over expanding into new
territories with quickly hacked-together code. Newly hacked code is prioritized
to first get it consistent with overall architecture, then functioning right,
and only then gets bells & whistles. Released CForms.
Vadim
PS Last one is a tease :)
