cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] A Groovy Kind of Sitemap
Date Thu, 29 Jul 2004 17:34:29 GMT
Steven Noels wrote:

> On 29 Jul 2004, at 09:19, Marc Portier wrote:
>> Rest assured I'm equally concerned with a number of other voices here 
>> about (using Ugo's wording) 'giving just more rope to hang yourself in'
>> However, when I see people 'removing and merging' then I can only see 
>> less rope :-)
>> IMHO we need to be honest/modest about how far any cocoon-user 
>> actually wants to be 'guided' and 'helped'.
> Collating both points into one concern: with the current Cocoon, we 
> already provide quite some rope, in the sense that I've seen a 
> separation between what developers *intend* to be used, and what users 
> *want* to use of Cocoon's broad set of features.
> Contrarily to httpd.conf/mod_rewrite-land, where there's "just the HTTP 
> spec" to implement, we are at liberty to put any kind of behaviour in 
> any component or block of Cocoon. That leads us to the situation where a 
> developer can create a block of functionality just to get a feel of 
> whether it makes any sense, but suddenly users pick it up and start 
> exploiting the thing as if it is production-ready code, expecting or 
> hoping for some form of support, even when they exploit it beyond what 
> it has been intended for.
> I believe the Cocoon users expect guidance and help beyond what they get 
> now, and we shouldn't provide more scriptable rope to hang themselves 
> with. This of course depends on what we believe Joe Average Cocoon user 
> is - and if we expect Joe to subscribe to the developers list to 
> understand what our intentions were. :-)

A little bit of history is needed:

- at the beginning there was no sitemap. all the pipeline machinery was 
"embedded" into documents using processing instructions. when it was 
proposed to move on, nobody ever objected.

- cocoon was still a publishing framework. this means it was meant to 
respond to "GET" requests. Pier and I sat down in his office in Erba 
(CO) in Italy and created the first draft of the sitemap. This was 4 
years ago. Given the high declarativity of the sitemap and given the 
impressive mind-bending nature of declarative languages that we had 
experienced for the first time a few years earlier with XSLT, the use of 
XSLT as a guiding path (and Pier's previous experience at IBM with 
StyleBook) was a no brainer. We *never* thought about a different syntax.

- the sitemap has not changed since then, if only a few things, mostly 
actions, and I was against them, but I saw the need and had no better 
idea (and no time at that time to spend more on it).

- actions soon showed weaknesses because the degree of reusability of 
actions is *much* lower than that of any other kind of sitemap 
component, showing that they are misplaced.

- the need to separate "resource production" from "flow control" can be 
seen as an extension of MVC where the view is a pipeline, the controller 
is a mix of flow control, business logic and glue between the two and 
the model is whatever you use to pass data from the two.

At this point, I went to Giacomo's in Zurich to talk about the 
"flowmap", as we called it at that time. We were so much ingrained into 
finite state machines that we didn't even think about the ability to 
"freeze the execution state" (which is what continuations are all about).

The flowmap, written in XML, was written on a few whiteboards, but it 
was so ugly that it was never even written into an RT.

It was Ovidiu that came with that idea and radically changed my way of 
thinking about this "flowmap", which soon became "flowscript".

                                   - o -

Now, for those who were not there at that time: Ovidiu's proposal was 
*NOT* accepted happily. For the most part, it was not understood until 
several months later. Any mind-bending change of direction is, at first, 
perceived as creating instability.

Add the fact that Ovidiu's examples were in Scheme (not exactly a 
friendly language for {}-oriented people like java programmers), but the 
real problem, IMO, was that it was "sinful" for many reasons:

  1) weak-typing
  2) interpreted scripting (perceived as too slow)
  3) esoteric concepts (continuations)
  4) weird syntax (scheme)

it was too much change to percieve anything useful from it.

There was *a lot* of resistance to his proposal, but I personally saw a 
great deal of value in what he was doing (the ability to get rid of FSM 
once and for all!), showing us a path where we could finally get rid of 
action pollution in the sitemap.

Ovidiu was allowed to create a private branch inside the cocoon CVS 
(codename "schecoon" out of "scheme-cocoon") and we let him play.

Later, upon our suggestions that Scheme's syntax was too hard for our 
audience to understand, he found Chris' version of Rhino with 
continuations and the rest is history.

                                   - o -


Ugo (like many others, myself included) is sick of being scared with the 
complexity of cocoon's code, which strongly reduced his ability to 
improve on it. His "extreme programming" approach is rather evident: do 
the simplest thing that can possibly work.

Laziness is a value: it minimizes energy dispersion... something that 
Avalon and its mindset (my fault there, I admit) didn't consider at all.

Cocoon is, today, a very different beast that it used to be, but what is 
it's value? its XML centricity or rapid-yet-solid web development?

I say rapid-yet-solid web development. thru SoC. which, at times, makes 
great use of XML.

We marketed cocoon as an xml publishing framework for the longest time, 
but we found out, down the road, that the real value was the application 
of separations and the incredibly useful notion of "first class objects" 
as semi-structured pipeline components!

If you *really* think about it, there is *NOTHING* about XML in that.

SAX is *NOT* XML. SAX is an event model for streaming semistructured 
multi-dimensional data. Unlike regular streams that have no structure 
and therefore require parsing/serializing at every pipeline stage.

Some say: why don't we go Apache 2.0 filters then? Here are the reasons:

  1) because they don't work on SAX events, they work on byte streams.
  2) because there is no notion of selection
  3) because there is no notion of views
  4) because there is no notion of pipeline caching machinery
  5) because there is no notion of sub-pipelining
     ... and so on (there are more!)

Apache 2.0 filters are *very* useful (in fact the mod_proxy/mod_cache 
separation alone gives a reason to migrate to 2.0.x from 1.3.x) but they 
are laughably simple compared to the pipeline system we have in place.

                                  - o -

Instead of arguing about the status quo, let's give Ugo the space he 
needs to show us where we can innovate.

If Cocoon is what it is today, it's not because we remained where we 
were, but because we allowed people to innovate internally and with an 
open and friendly attitude and we "guided" our user base in new 
directions and never failed to provide them a better environment then 

Let's NOT forget that.


View raw message