Sylvain,
I'm glad to see that, more than one year after my "Butterfly
Manifesto" [1], people are finally coming to the realization that we
need a revolutionary change in Cocoon, a change that is targeted
towards a radical simplification. Better late than never :-).
In order to proceed from here, I think we need to decide what we want
Cocoon to be. At present, I see Cocoon as wanting to be at least
three different things, all together:
1) A web publishing framework.
2) A web application framework
3) An XML-based sort of engine or hub for producing and consuming web
services.
Personally, I'm not that much interested in either 1 or 3 above, even
though my next project assignment will probably involve building a
publishing system for producing a printed book and people are trying
to push me towards using Cocoon for doing 3.
But I think 1 isn't particularly fun and can be tackled using Cocoon
2.1, and there are probably better solutions for 3 already. Which
leaves us with 2, which isn't all that bad if what you want is build
the next great Web 2.0 service, earn a decent income selling
subscriptions or ad space, and later make a boatload of money by
selling to Google, Yahoo or Microsoft ;). Or even if you want to
provide applications for your customers or for your internal IT
department, which is probably what most of us do day in, day out.
To reach this elusive goal, we need a platform that makes it easy to
support Ajax and to provide and consume RESTful web services. We need
it to be agile, as in needing the shortest roundtrip time between
doing an edit and seeing its efffect in a browser window. We need to
support a simple persistance mechanism on top of SQL, like
ActiveRecord (jDBI looks great for this, but we must leave the door
open for people wanting to use Hibernate or JDO or whatever).
I agree we need a simple API for the sitemap that makes pipelines
composable and content-aware. With such an API, it will be easy to
provide either a declarative sitemap configuration file or a
programmatic one, using any scripting language that runs on the JVM.
I'd also like the controller to be able to adopt the Ajax paradigm
(actually the "Asynchronous XML over HTTP" part of it). By this I
mean that it should be possible to use something similar to the
XMLHttpRequest object to invoke an external service, process the
response using DOM or StAX and, once all pending requests have been
satisfied, serve the response to the client. Great for doing mashups.
I know it's premature to talk about implementation issues, but since
Carsten brought up the issue first, y'all know I have a fondness for
Spring, so you know where my heart lies.
To Daniel and the others working on Cocoon 2.2: You have a tough job
ahead and it's going to get even tougher now that everyone is jumping
up and down around this new shiny thing. I'm afraid you're not going
to get much help from others, but what you're doing is incredibly
valuable for all those companies that have an interest in supporting
existing Cocoon 2 solutions, which will be around for a long time. I
think what these companies should do is to directly and financially
support this effort. It's not going to be fun (for most people, I
mean) and it's not going to be rewarded by immense popularity and
recognition, so I think it has to be paid for.
Just my 0.02€,
Ugo
[1]: http://wiki.apache.org/cocoon/ButterflyManifesto
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source Zone: http://oszone.org/
Wine & Food Blog: http://www.divinocibo.it/
