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
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
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 Wallez - http://bluxte.net