cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [control flow] names and concepts [was: changes and new sample]
Date Sat, 14 Sep 2002 10:47:57 GMT
Conal Tuohy wrote:

> The flow layer is not continuous, but discrete, isn't that right? So the
> inaptness is with "flow".

Well, that's one way to look at it. But I have another one: the 'flow
layer' tries to make 'continous' (or 'as procedural as possible')
something that is intrinsically discrete (the web: based on a stateless
protocol and on a REST-like network architecture).

This is *exactly* the same evolutionary pattern that was implied when
the 'goto' statement was considered dangerous and an anti-pattern for
its usage was created: the goal was to make something that is
instrinsically discrete (CPU operations) appears as a continous flow of
operativity (which is much more similar at the way people see the

> > A better alternative could be to use 'pipelines and valves', but this
> > collides with the use of 'valves' in Tomcat 4.x
> yes.
> "Director" is overloaded but perhaps a metaphor of "steering a course" would
> be be similar?
> <map:steer course="blah"/> or something

Yes, this is an alternative, but I'd like to stick to the concept of
'proceduralizing' something that was previously described as FSM (in the
best case) or with a sparse fragmented transitional matrix (in the
normal case).

This has nothing to do with 'steering a course', IMO.

> > I know that 'calling a flow' is not really meaningful, in fact,
> > 'hand-over to the resource flow' would be a better description of the
> > action, but I'm not really worried by these things. The sitemap shows
> > that once people like a concept, they don't mind sticking to
> > a new name
> > or even more, replace the most used meaning of that word for the new
> > meaning.
> But for new users the terminology is more important. There are a lot of
> features in Cocoon! If a feature of Cocoon has an inapt name its real
> function may be effectively hidden from new users. Terminology that is based
> on an apt metaphor can be more easily learned and will cause less confusion
> over semantics in the long term.

I can't agree more. But as you can see above, there are many different
ways to see the same technology from a metaphorical point of view. Once
we choose a terminology and the metaphor we associate with it, it's our
goal to remain coherent so that users aren't driven in different

But I feel we have been pretty good at metaphorical coherence so far:
everytime we invent or introduce something new, lots of reasoning is put
into naming, architectures and design. And I think this is something
that shows once users get the picture.

Stefano Mazzocchi                               <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message