Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <492D2614.6060405@apache.org>
Date: Wed, 26 Nov 2008 11:33:56 +0100
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Where is Cocoon 3 going to?
References: <4925FD53.1020002@apache.org> <4925FFB0.8090503@tuffmail.com>
 <F8E386B54CE3E6408F3A32ABB9A7908A01537838@hai02.hippointern.lan>
 <20081125000506.GB376@igg.indexgeo.com.au> <492BE41D.50904@tuffmail.com>
 <492C0AA5.4030209@apache.org> <492C791B.3020600@tuffmail.com>
In-Reply-To: <492C791B.3020600@tuffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Grzegorz Kossakowski wrote:
> I guess this e-mail is already long enough to cut it here. If you are interested in my ideas on providing functional implementation of sitemap (that would be inspired by some characteristics of bash) I could write a little bit more on it with some details.
>   

Interesting thoughts, especially as I am myself interested in functional 
programming, which I started with Javascript, then learned Erlang and 
looked at Scala as a very interesting way to bring those programming 
paradigms to the Java platform.

Now we have to think about what this community is about, and what we can 
do to make it successful again. An open source community is a delicate 
balance between interest of developers in developing the product, and 
interest of users in actually using the product. The concept of 
"interest" covers many different aspects: for developers, this includes 
a combination of hacking pleasure, pure altruism, strengthening a 
business related to the product, socializing with like-minded people, 
etc. For users, it includes being able to be efficient and productive, 
finding support from developers and other users, and being able to 
understand the product to tune it and ultimately write bugfixes and 
patches, opening the way to committership.

The Cocoon community has been a bit special in this regard, since Cocoon 
allows to do quite complex stuff with a small amount of "code" (sitemap 
and XSLT are code) and without requiring strong programming skills. I 
remember someone sending a "Thank you" email, explaining how Cocoon 
allowed him to do stuff he wouldn't have been able to do without it, and 
thus start a consulting business that allowed him to work from home and 
spend more time with his family. How rewarding for us developers! Cocoon 
allows less skilled users to _do_ stuff, and skilled developers to be 
highly productive. This is why this complex product attracted brillant 
innovation but at the same time was more accessible to average people 
than less sophisticated products.

Looking at our website, I think we have forgotten what forms our 
community: "Apache Cocoon is a Spring-based framework (since version 2.2 
of Cocoon) built around the concepts of separation of concerns and 
component-based development. Cocoon implements these concepts around the 
notion of component pipelines, each component on the pipeline 
specializing on a particular operation."

Well, Cocoon old-timers understand what it means (at least roughly in my 
case, as I never digged into blocks). Now put yourself as a newcomer, 
especially a less skilled person representing the largest part of our 
users. What the heck is this Cocoon stuff all about? What kind of 
problems does it solve? How is it different/better than other products I 
can find at Apache and elsewhere?

Cocoon has been very successful by being a superb integration platform 
for everything that can be represented as XML, and there are blocks for 
every Apache-compatible library that can produce or consume XML. Even 
music, and I've seen people's jaws dropping when I showed them the Bach 
prelude being processed in XSLT. Over time blocks have accumulated, the 
framework has been abstracted and modularized to become even more 
flexible and address even more problems, but this came with a price: 
newcomers simply can't grasp what Cocoon is about.

Also, Cocoon has been an incredible source of innovation, with its 
component architecture, the ReSTful sitemap, the mighty (but complex) 
portal, server-side scripting, continuations, etc. But the outside world 
has also innovated, and new frameworks/techniques have emerged, at all 
levels of the stack: Spring as a replacement for Avalon, Wicket for 
complex forms, GWT and many others for Ajax, aggregated pages and 
portals are now replaced with Ajax gadgets, etc.

The newer products aren't necessarily easier to use, but are probably 
easier to grasp because they do less, or have more introductory 
material, or are more "standard" (i.e. widely accepted, be it for good 
reasons or not). There also has been simpler approaches such as Django, 
Ruby on Rails, or the numerous PHP equivalents.

Coming back to the original proposal, my opinion is that writing Cocoon 
in a functional language would be a fun exercise, but nobody would use 
it because nobody in this community would understand it. Note that I say 
_this_ community, since for example the CouchDB community happily hacks 
hard-core functional Erlang.

Also we have to consider that the XML hype is fading away and that the 
times of "everything can be represented as XML" are over, for good 
reasons or not. Welcome JSON as a replacement to XML for data 
interchange, because it's much more lightweight, native in browsers, and 
more typed than XML (it has numbers, arrays, maps).

Considering this, my personal opinion is that XML pipelines still have a 
value, but this value has been reduced back to the original goals of 
Cocoon: document transformation for multiple presentations. But it's no 
more good as the foundation of a whole application since other 
techniques and new approaches (esp Ajax and JSON) have made it easier.

At least this is my feeling and own experience. At $work we have a 
full-ajax portal, and a very simple URL-matching Java library that has 
most of the sitemap matching features in a dozen classes, and a 
super-lightweight XML pipeline engine to adapt HTML pages for the web or 
mobile phones. And we use Wicket for data-intensive backoffice webapps.

So what does this all mean for our community? What community of users 
should we target? The historical community described above, or a new 
kind of community? What's in Cocoon to make it appealing to newcomers? 
XML pipelines, the sitemap, server-side scripting and continuations. 
Cocoon 2.2 has buried them under a huge technical and presentational 
complexity.

Cocoon 3 builds on these core values, but is already IMHO too complex by 
having more than a dozen different modules. Note that this complexity is 
more organizational than technical, but it makes it too difficult for 
people to find their way there (that was my case). Also, a complete 
rewrite is needed, but at the same time we should not forget all the 
technical expertise that has been put in Cocoon over the years (e.g. 
cache, work arounds for well-known Xalan quirks, etc) and completely 
reinvent the wheel. Difficult exercise.

I know this mail brings more questions than answers, and Cocoon has to 
reinvent itself, both from a technical and a community point of view. 
Are we ready for this reinvention? Can a consensus emerge on what it 
should be? The answer is ours.

Thanks for reading so far.

Sylvain

-- 
Sylvain Wallez - http://bluxte.net