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 -
Now.
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 before.
Let's NOT forget that.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
