cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject Re: [RT][long] Cocoon 3.0: the necessary mutation
Date Mon, 05 Dec 2005 08:34:25 GMT

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  

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 Cei
Tech Blog:
Open Source Zone:
Wine & Food Blog:

View raw message