Re: [control flow] names and concepts [was: changes and new sample]

[Ola Berg <ol...@arkitema.se>]

Brainstorm

1) What component is it that we speak of?

flow
controller
flow-controller
director
flow-director


This defines an application flow

<map:flow language=\"JavaScript\">
� <map:script src=\"blah.js\"/>
</map:flow>

A \"director\" in a play makes the actors act according to a script, it could work:

<map:director language=\"JavaScript\">
  <map:script src=\"blah.js\"/>
</map:director>


Now, what happens when it is time to act according to the script? Is the flow \"called\" or \"used\":

<map:call-flow ...

<map:use-flow ...

or is it a director that directs?

<map:direct ...

Suggestions:
use-flow
call-flow
direct


Personally, I like either \"flow\" and \"use-flow\" or \"director\" and \"direct\". On second thougt \"flow\" and \"use-flow\" is what I like best. (Part of the problem is that \"flow\" can be used both as a noun (the component) and as a verb (the action). \"use-flow\" makes up for this.).

my SEK 0.02, for all that it\'s worth...

/O


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [control flow] names and concepts [was: changes and new sample]

[Stefano Mazzocchi <st...@apache.org>]

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
world).

> > 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
directions. 

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                               <st...@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [control flow] names and concepts [was: changes and new sample]

[Conal Tuohy <co...@paradise.net.nz>]

> Ola Berg wrote:

> > Personally, I like either \"flow\" and \"use-flow\" or
> \"director\" and \"direct\". On second thougt \"flow\" and
> \"use-flow\" is what I like best. (Part of the problem is
> that \"flow\" can be used both as a noun (the component) and
> as a verb (the action). \"use-flow\" makes up for this.).

Stefano Mazzocchi wrote:
> The 'actor/director' metaphore has been extensively used in
> Avalon and I
> don't want them to collide here.

fair enough - but I think Ola is right that the director metaphor is more
apt...

> Also, what I don't find fitting in the actor/director metaphor is the
> unbroken seemless continuation perception that 'flowing' gives. When
> something flows, it's normally continously flowing or there
> is a problem
> (water, oil, eletric current, air)

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

> 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

> 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.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [control flow] names and concepts [was: changes and new sample]

[Stefano Mazzocchi <st...@apache.org>]

Ola Berg wrote:
> 
> Brainstorm
> 
> 1) What component is it that we speak of?
> 
> flow
> controller
> flow-controller
> director
> flow-director
> 
> This defines an application flow
> 
> <map:flow language=\"JavaScript\">
>   <map:script src=\"blah.js\"/>
> </map:flow>
> 
> A \"director\" in a play makes the actors act according to a script, it could work:
> 
> <map:director language=\"JavaScript\">
>   <map:script src=\"blah.js\"/>
> </map:director>
> 
> Now, what happens when it is time to act according to the script? Is the flow \"called\" or \"used\":
> 
> <map:call-flow ...
> 
> <map:use-flow ...
> 
> or is it a director that directs?
> 
> <map:direct ...
> 
> Suggestions:
> use-flow
> call-flow
> direct
> 
> Personally, I like either \"flow\" and \"use-flow\" or \"director\" and \"direct\". On second thougt \"flow\" and \"use-flow\" is what I like best. (Part of the problem is that \"flow\" can be used both as a noun (the component) and as a verb (the action). \"use-flow\" makes up for this.).

The 'actor/director' metaphore has been extensively used in Avalon and I
don't want them to collide here.

Also, what I don't find fitting in the actor/director metaphor is the
unbroken seemless continuation perception that 'flowing' gives. When
something flows, it's normally continously flowing or there is a problem
(water, oil, eletric current, air)

A better alternative could be to use 'pipelines and valves', but this
collides with the use of 'valves' in Tomcat 4.x

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.

I forecast the same happening for the flow concept.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org