cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: [RT] Generalizing the flow
Date Sat, 05 Jul 2003 17:07:51 GMT
Sylvain Wallez wrote:

> Christopher Oliver wrote:
> <snip/>
>> The problem I have with the proposed changes is that they obscure the 
>> design and use of flowscript (in order to support some other 
>> unspecified "flow engine", which to appears to not really have the 
>> same "interface" as the flowscript engine, IMO). To try to force them 
>> to use the same sitemap constructs seems unnecessary and 
>> counterproductive.
> First of all, the usual disclaimer, as the continuation-based flow 
> script has unfortunately become a kind of religion in Cocoon : I love 
> the flowscript and continuations, and I do use it for real-world 
> applications. But I'd also like other "religions" to be able to exist.
> Now back to the discussion...
> What is the more obscure :
> - "Intepreter" or "FlowEngine" ? "Interpreter" is something that 
> interprets a language, and not something that drives the application 
> flow. 

Interpreters are things that have "functions" and "continuations". What 
are "FlowEngines" exactly?

> - "WebContinuation" or "FlowState" ? Continuations are a particular 
> implementation of a way to store the flow state. 

> - <map:call function> or <map:call flow> ? "function" is a related to 
> entry points in a functional language. How does this relate to 
> application flow ? 

With Flowscript, the application (page) flow _is_ actually defined by a 
functional programming language. That's the whole point. Your proposed 
name changes obscure this, IMO.

> - <map:call continuation> or <map:call state> ? Again, "continuation" 
> is a particular implementation of the flow state.

Well, right now it's the key concept that makes Flowscript possible. I 
think it's a little more than a mere implementation detail.

> I really think the proposed changes better represent the real concepts 
> behind the flow stuff rather than the current names which are more 
> related to the particular implementation we have today.
> What do others think ?
This discussion has clearly digressed into a subjective discussion about 
names. So -0 to any name changes.

View raw message