RE: [Vote] Controller/Sitemap integration
Stephan Michels wrote:
map:pipeline
[...]
map:continue type=petshop id={1}/
[...]
/map:pipeline
I think it's a potential source of confusion to have id attributes which
are not of type ID (i.e. they are not unique identifiers of elements in the
sitemap). Of course, I realise that id is just an abbreviation for
identifier, and that it's purely conventional that id attributes are of
type ID, but I think we should respect this very common convention because
doing so will lower the cognitive burden for people learning Cocoon flow.
http://www.w3.org/TR/REC-xml#id
Similarly, a newbie might expect a state-id attribute to be of type IDREF,
which is a mark against it IMHO. http://www.w3.org/TR/REC-xml#idref
And again, that's why I think src would be a poor name for the same
attribute, because an attribute with this name would conventionally contain
a URI. http://www.w3.org/TR/xmlschema-2/#anyURI
That's why I'd prefer any other of the alternative names proposed: state,
from, continue, or flow.
Cheers
Con
Re: [Vote] Controller/Sitemap integration
On Thu, 17 Jul 2003, Joerg Heinicke wrote: Reinhard Pötz wrote: As I have been confused by all those suggestions you can find a summary here: http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration Cool summary, really helps a lot. And here the cool voting matrix :) | A | B | C | D | E | |---|---|---|---|---| | | | | | | V1 | -1 | +0 | +0 | +.5 | +1 | | | | | | | V2 | +1 | -1 | -0 | +.5 | -1 | | | | | | | V3 | ?? | +.5 | -1 | \ | \ | | | | | | | V4 | \ | -1 | -0 | \ | \ | | | | | | | V5 | \ | +1 | +.5 | \ | \ | | | | | | | V6 | \ | \ | -1 | \ | \ | | | | | | | V7 | \ | \ | +1 | \ | \ | | | | | | | |---|---|---|---|---| What is the difference between A V1 and A V2? Only the map:flows/? And what does it mean? B V5 was missing. From Marc's answer I guess he meant this, but chooses V1. Don't you think that this makes the voting really difficult ;-) A: V1 B: V2 C: V1 with flow instead of type D: V2 E: V2 BTW, I think it too early to vote on this. If I must decide now, all will be carved in stone. I think we should leave A-C as it is for 2.1. And postpone the discussion to the post-2.1-era. For my part, I must have first two implementations to find more generalized contract, which we don't have at this point. So my vote would like: Should we postpone the generalisation to the post-2.1-era, and hazard with the consequences, that we maybe change the sitemap syntax of a released version of Cocoon? +1 Stephan.
Re: [Vote] Controller/Sitemap integration
Reinhard Pötz wrote: Coming back on the vote: the issue here is not really about renaming these classes, but about introducing this FlowState abstraction layer. Your remark rightfully makes me see I was starting to overlook the subtle nuance. all in all, I have the feeling this is not really part of the public interface we want to nail down here and now ? (meaning that I believe the introduction of this layer could be done whithout much effect on applications that just use an certain flow implementation, of course the flowprocessor impl's themselves would have some refactoring ahead) I don't understand the current flow implementation from Ovidiu and Chris or Sylvain's and your proposal in all depth but whatever the future brings should only change implementations - the user shouldn't even notice that something has changed. I share your hope the same remark probably goes for the FlowEngine/Processor and might explain our lesser natural connection to these issues on the table? Sorry, I don't understand what you mean with this last paragraph. yeah, I must say it was very poetic :-) I noticed much of us have expressed the indifference feeling on this engine/processor issue, we'ld have to give it a name here and now, but I guess all of us kind of 'feel' that changing this in the event we have built up enough evidence for either case will not be of that high influence... Reinhard -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Controller/Sitemap integration
Stephan Michels wrote: On Thu, 17 Jul 2003, Joerg Heinicke wrote: Reinhard Pötz wrote: As I have been confused by all those suggestions you can find a summary here: http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration Cool summary, really helps a lot. And here the cool voting matrix :) | A | B | C | D | E | |---|---|---|---|---| | | | | | | V1 | -1 | +0 | +0 | +.5 | +1 | | | | | | | V2 | +1 | -1 | -0 | +.5 | -1 | | | | | | | V3 | ?? | +.5 | -1 | \ | \ | | | | | | | V4 | \ | -1 | -0 | \ | \ | | | | | | | V5 | \ | +1 | +.5 | \ | \ | | | | | | | V6 | \ | \ | -1 | \ | \ | | | | | | | V7 | \ | \ | +1 | \ | \ | | | | | | | |---|---|---|---|---| What is the difference between A V1 and A V2? Only the map:flows/? And what does it mean? B V5 was missing. From Marc's answer I guess he meant this, but chooses V1. Don't you think that this makes the voting really difficult ;-) I think the roundup and visualization really helps it's just that the voting _is_ complex since there have been a lot of arguments on the table the alternative would be to go into the meta-level of discussing which arguments are valid and which not (hardly easier since a lot of this is personal perception and not to be black/white or true/false) A: V1 B: V2 C: V1 with flow instead of type D: V2 E: V2 BTW, I think it too early to vote on this. If I must decide now, all will be carved in stone. I think we should leave A-C as it is for 2.1. And postpone the discussion to the post-2.1-era. For my part, I must have first two implementations to find more generalized contract, which we don't have at this point. So my vote would like: Should we postpone the generalisation to the post-2.1-era, and hazard with the consequences, that we maybe change the sitemap syntax of a released version of Cocoon? +1 I partially agree: - refactoring and continuous design is the reality of this world: pretending to 'carve in stone' is close to telling lies - the stress on getting the abstract level right without the insight of enough detail in the multiple implementations feels unnatural (given that refactoring has become so easy) But I also see the other side of things: - refactoring and change can be a give to those that know the internals and live by the laws of cvs-head, the same level of flexibility eagerness might not be found in settings where upgrading to the latest stable cocoon release is something that is scheduled at best once a year - it might be a challenge to abstract things upfront, but brave man like us do not fear challenges ;-) So maybe the consensus getting us into beta stage can maybe be reached by splitting up - vote on A-C now, carve in 'sand-stone': these are related to non-coding end-users of flow, transition from one to the other costs more - decide on D-E _for_ now, carve in 'yoghurt': this is related to developer decisions, dependent developers would probably less mind if changes occur, their refactoring IDE's would help them out a great deal... in both cases we (must realize that we) are making a best estimate on what we know now, that is just how life is... the remaining argument to actually decide here and now is it gets us out of the catch-22: it enables more nicely the alternative implementations that will get us the deeper insight we're missing to date what do others think? (I might be missing the complete point of release management here, I don't mind if someone points that out to me) Stephan. -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: [Vote] Controller/Sitemap integration
-Original Message-
From: Stephan Michels
On Fri, 18 Jul 2003, Reinhard Pötz wrote:
From: Stephan Michels [mailto:[EMAIL PROTECTED]
A: V1
Why do you want implementation details in the element: map:flows
...
map:flow name=java type=atct class=org.apache.cocoon/
map:flow name=fsm type=fsm src=descriptors/fsm.xml/
---
/map:flows
I don't think that class or src should be attributes of
map:flow/.
It should go into the configuration, shouldn't it?
I you think of Configuration class, you can do both. But you
are right in the case of validation(which is in the current
case terrible difficult), the second option is better.
I change my A: V1 to A: V2, okay?
B: V2
C: V1 with flow instead of type
to use the flow attribute to determine which implementation is used
doesn't make really sense to me. Everywhere else the type
attribute is
used. I would use the flow attribute to give the flow
processor a hint
Which implementation you use is defined in map:flow
map:initiate - select flow - map:flow \\
- select implementation - flow-processor
Ohh moment, what makes the flow component different from
other sitemap components? Nothing!
From a technical POV you are completly right but I share Stefano's idea
that we should show our users that the flow component is different from
the sitemap components. So I'm -1 on this.
map:components
map:flow name=petshop class=
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
reload-scriptstrue/reload-scripts
check-time4000/check-time
script src=flow/PetStoreImpl.js/
script src=flow/petstore.js/
/map:flow
map:components
... so I like the new section map:flows.../map:flows more. See the
reasons above.
And I think it is FS to determine the implementation
(org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter) at
sitemap level.
Do you have a usecase which makes this necessary? I wrote a lot of JS
flow scripts and haven't had a need for this yet.
map:flows
map:flow name=petshop class=
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
reload-scriptstrue/reload-scripts
check-time4000/check-time
script src=flow/PetStoreImpl.js/
script src=flow/petstore.js/
/map:flow
/map:flows
map:initiate type=petshop start=addItem/
map:continue type=petshop id={1}/
Hey, I love this :)
I think this obscures that a flow processor/engine is used. Of course
this makes only sense in connection with map:flows.../map:flows.
Therefore I like following syntax more.
map:initiate flow=addItem type=petshop /
map:continue flow={1} type=petshop /
Would you be fine with this?
Cheers,
Reinhard
RE: [Vote] Controller/Sitemap integration
On Fri, 18 Jul 2003, Reinhard Pötz wrote:
From: Stephan Michels
map:initiate - select flow - map:flow \\
- select implementation - flow-processor
Ohh moment, what makes the flow component different from
other sitemap components? Nothing!
From a technical POV you are completly right but I share Stefano's idea
that we should show our users that the flow component is different from
the sitemap components. So I'm -1 on this.
map:components
map:flow name=petshop class=
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
reload-scriptstrue/reload-scripts
check-time4000/check-time
script src=flow/PetStoreImpl.js/
script src=flow/petstore.js/
/map:flow
map:components
... so I like the new section map:flows.../map:flows more. See the
reasons above.
Oh yes, I mean
map:components
map:flows
map:flow name=petshop class=
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
reload-scriptstrue/reload-scripts
check-time4000/check-time
script src=flow/PetStoreImpl.js/
script src=flow/petstore.js/
/map:flow
/map:flows
map:components
like every other components.
And I think it is FS to determine the implementation
(org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter) at
sitemap level.
Do you have a usecase which makes this necessary? I wrote a lot of JS
flow scripts and haven't had a need for this yet.
1. Usecase: You don't want to use flows - remove the flow section
2. Usecase: You have different flows in the same map.
3. Usecase: You use different implementations in the same map.
The fact, that specifying of components in the sitemap is in general
a bad pratice, is another point, but don't want to discuss
here(,perhaps later :))
map:initiate type=petshop start=addItem/
map:continue type=petshop id={1}/
Hey, I love this :)
I think this obscures that a flow processor/engine is used. Of course
this makes only sense in connection with map:flows.../map:flows.
Therefore I like following syntax more.
map:initiate flow=addItem type=petshop /
map:continue flow={1} type=petshop /
Would you be fine with this?
I thought with @type to combine the implementation(Javascript) and
instance(petstore.js), which I see as practice, which already used
with the other components.
Another way could be
map:initiate flow=addItem type=petshop src=flow/petstore.js/
map:continue flow={1} type=petshop src=flow/petstore.js/
And the flow processor could cache the instance with @src
as key.
But nevertheless, I like most
map:components
map:flows
map:flow name=petshop class=
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter
reload-scriptstrue/reload-scripts
check-time4000/check-time
script src=flow/PetStoreImpl.js/
script src=flow/petstore.js/
/map:flow
/map:flows
map:components
map:pipeline
[...]
map:initiate type=petshop start=addItem/
[...]
/map:pipeline
map:pipeline
[...]
map:continue type=petshop id={1}/
[...]
/map:pipeline
This makes the concept really symmetric to the other
components, and can signal that the continuations
are the successor of the actions.
Stephan.5~
RE: [Vote] Controller/Sitemap integration
From: Joerg Heinicke
Because of this upcomming naming discussion I guess the vote
started to
early.
Unfortunatly you are right. After the balkanization discussion I
thought that the people here are satisfied with Marc's/Sylvain's
proposal. In the meantime I'm really tired of waiting for the 2.1
release (yes, I want to use it in production -- I don't have problems
with CVS versions but many customers have!) ... therefore my try with
the vote ...
This was also the reason why I voted +0. Those changes would have been
possible for a later release and the migration would have been very
easy.
First all alternatives should be known. But the
additions Stephan
provided make sense (see inline).
Stephan Michels wrote:
[A] The Cocoon Advanced Control Flow provides a
controller that is
linked into the sitemap (as **child element** of map:sitemap
.../:
map:flow type=[yourEngine]
[configuration]
/map:flow
This reflects that the flow is not a *usual* sitemap
resource but
something else.
The point, which irritates me, is that you don't have a
identifier to
address the script/whatever.
So my favorite choise will be
map:flows
map:flow name=js type=javascript
script src=flow/PetStoreImpl.js/
script src=flow/petstore.js/
/map:flow
map:flow name=java type=atct class=org.apache.cocoon/
map:flow name=fsm type=fsm src=descriptors/fsm.xml/
/map:flows
So this will be coherent with the other objects.
Which leads the sentence This reflects that the flow is not
a *usual*
sitemap resource but something else. ad absurdum :)
I'm -0 on this changes to my proposal (see Jörg's argument)
[B] The controller is called by:
map:call flow=[yourFlow]
map:parameter name=x value=y/
/map:call
Seems fine, an alternative will be
map:initiate flow=js call=[Javascript function]
map:parameter
name=x value=y/ /map:initiate
map:initiate type=java call=[Java method] map:parameter
name=x value=y/ /map:call
map:initiate type=fsm call=[Name of state] map:parameter
name=x value=y/ /map:initiate
I like the combination of initiate/continue
initiate/continue is ok, but what about keeping syntax of all sitemap
objects using @type and @src:
map:initiate type=java src=[Java method]/
Or is it to far away from the sense or even misleading?
[C] A state of the controller is called by:
map:call state=
map:parameter name=x value=y/
/map:call
We don't call states in this sense. We continue
a continuation ;-)
I guess map:continue continuation={1}/ is bad.
map:continue src={1}/
or
map:continue id={1}/
Same like above, so I prefer @src.
[D] All flow interpreters[3] are Avalon components and declared
in the cocoon.xonf:
flow-engine default=[yourController] logger=[yourLogger]
...
/flow-engine
+1, except the name, see next.
[E] Changes in the current Javascript implementation:
- rename Interpreter to FlowEngine,
Again, to be coherent my favorite is
flow-processor like xslt-processor and xpath-processor, or
treeprocessor.
flow-engine vs. flow-processor - I don't know ...
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Here I prefer the States for the reasons Marc provided, so +1 here.
Yes, the Continuation represents a state, but to make a clear
difference as a new concept, I think 'Continuation' is
accurate. But
'Web..'?!
- rename WebContinuation to Continuation, and accordingly
WebContinuationManager to ContinuationManager.
If not states, but continuations at least remove 'Web' = +1
Conal Tuohy wrote:
What about map:continue from=.../
Hmm, I don't really like it. We don't need an English sentence :)
Otherwise you could also change to map:generate from=foo.xml/,
map:transform with=bar.xsl/ and map:serialize as=html/. @type
and @src is a good abstraction IMO.
Joerg
Re: [Vote] Controller/Sitemap integration
On Thu, 17 Jul 2003, Joerg Heinicke wrote:
Stephan Michels wrote:
map:flows
map:flow name=js type=javascript
script src=flow/PetStoreImpl.js/
script src=flow/petstore.js/
/map:flow
map:flow name=java type=atct class=org.apache.cocoon/
map:flow name=fsm type=fsm src=descriptors/fsm.xml/
/map:flows
So this will be coherent with the other objects.
Which leads the sentence This reflects that the flow is not a *usual*
sitemap resource but something else. ad absurdum :)
Okay, but how should a different implemenation look like?
[B] The controller is called by:
map:call flow=[yourFlow]
map:parameter name=x value=y/
/map:call
Seems fine, an alternative will be
map:initiate flow=js call=[Javascript function]
map:parameter name=x value=y/
/map:initiate
map:initiate type=java call=[Java method]
map:parameter name=x value=y/
/map:call
map:initiate type=fsm call=[Name of state]
map:parameter name=x value=y/
/map:initiate
I like the combination of initiate/continue
initiate/continue is ok, but what about keeping syntax of all sitemap
objects using @type and @src:
map:initiate type=java src=[Java method]/
Or is it to far away from the sense or even misleading?
+1
[C] A state of the controller is called by:
map:call state=
map:parameter name=x value=y/
/map:call
We don't call states in this sense. We continue
a continuation ;-)
I guess map:continue continuation={1}/ is bad.
map:continue src={1}/
or
map:continue id={1}/
Same like above, so I prefer @src.
+1
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Here I prefer the States for the reasons Marc provided, so +1 here.
+0
Conal Tuohy wrote:
What about map:continue from=.../
Hmm, I don't really like it. We don't need an English sentence :)
Otherwise you could also change to map:generate from=foo.xml/,
map:transform with=bar.xsl/ and map:serialize as=html/. @type
and @src is a good abstraction IMO.
I think in the same direction, @src and @type are more intuitive.
Stephan.
RE: [Vote] Controller/Sitemap integration
As I have been confused by all those suggestions you can find a summary here: http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration After the discussion and all your opinions I would prefer: Integrating the flow processor/engine: -- map:flows map:flow name=js type=javascript script src=flow/PetStoreImpl.js/ script src=flow/petstore.js/ /map:flow map:flow name=java type=atct class src=org.apache.cocoon/ /map:flow map:flow name=fsm type=fsm blabla src=descriptors/fsm.xml/ /map:flow /map:flows ... in order to be coherent. Please note that the flow element only has name and type. All other things are IMO part of the configuration (... someone proposed to have a class attribute -- that's useless for e.g. the JavaScript implementation) Call a flow the first time: --- map:call flow=[yourFlow] type=js map:parameter name=x value=y/ /map:call I prefer call because this makes the most sense for me. But I'm +0.5 with initialize. And I like the word flow otherwise it is totally obscured that it is part of the flow implementation. Please note again that we need a type attribute again. ... and I don't like src because src means something different everywhere in Cocoon (something that can be called using the SoureResolver ...) Continue a flow: map:continue id=... type=js map:parameter name=x value=y/ /map:continue Again, I don't like src (see reasons above) and we need the type attribute. Component declaration: -- I'm indifferent on this ... And here a completly new alternatvie (at least for this discussion:) map:flow call= type=js map:parameter name=x value=y/ /map:flow and map:flow continue= type=java map:parameter name=x value=y/ /map:flow This makes for me the greatest sense because you still know that you deal with flow and this is not obscured by call, continue, initialize or whatever. Perhaps, this would make a renaming of the declaration in map:flows.../map:flows necessary. What do you think? Cheers, Reinhard
Re: [Vote] Controller/Sitemap integration
Stephan Michels wrote:
...
We don't call states in this sense. We continue
a continuation ;-)
I guess map:continue continuation={1}/ is bad.
map:continue src={1}/
or
map:continue id={1}/
...
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Yes, the Continuation represents a state, but to make a clear
difference as a new concept, I think 'Continuation' is accurate.
But 'Web..'?!
- rename WebContinuation to Continuation, and accordingly
WebContinuationManager to ContinuationManager.
I guess I'm a little confused at the general agreement on this naming
using continuation. I thought I was hearing in Sylvain's original RT
that continuations may not be the only implementation. I don't have a
problem with any of the new names suggested which is why I'm not really
adding anything to the discussion at this point, but I don't want to
have the discussion miss this point.
Could someone who resonates with the vision for these other potential
(non javascript-with-continuations) implementations of flow comment on
this quickly? If it satisfies you, I have no personal objection.
Geoff
Re: [Vote] Controller/Sitemap integration
On Thu, 17 Jul 2003, Geoff Howard wrote:
Stephan Michels wrote:
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Yes, the Continuation represents a state, but to make a clear
difference as a new concept, I think 'Continuation' is accurate.
But 'Web..'?!
- rename WebContinuation to Continuation, and accordingly
WebContinuationManager to ContinuationManager.
I guess I'm a little confused at the general agreement on this naming
using continuation. I thought I was hearing in Sylvain's original RT
that continuations may not be the only implementation. I don't have a
problem with any of the new names suggested which is why I'm not really
adding anything to the discussion at this point, but I don't want to
have the discussion miss this point.
Could someone who resonates with the vision for these other potential
(non javascript-with-continuations) implementations of flow comment on
this quickly? If it satisfies you, I have no personal objection.
A little example:
function myFunc()
{
x = bla;
sendPageAndWait(first)
if (answer = sucess)
y = blub;
sendPageAndWait(choice)
else
y = yagh;
sendPageAndWait(choice)
sendPageAndWait(last)
}
Here you have four different states:
state 0:
x = bla;
sendPage(first)
state 1:
y = blub;
sendPage(choice)
state 2:
y = yagh;
sendPage(choice)
state 3:
sendPage(last)
And several transitions:
state 0 - state 1 if answer = sucess
state 0 - state 2 otherwise
state 1 - state 3
state 2 - state 3
So, here we have a DFA.
The 'continuation' means to freeze the current state of the execution.
The benefit of the continuations are that you have a history
of the states, which you had traversed. And like a backtracking
algorithm, you can go back to a previous state and follow another
route.
So, the answer is, it is sufficient to have the 'history of states'
to take a new name like 'continuation' instead of simple 'state'?
I think yes.
Stephan.
RE: [Vote] Controller/Sitemap integration
From: Stephan Michels
On Thu, 17 Jul 2003, Geoff Howard wrote:
Stephan Michels wrote:
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Yes, the Continuation represents a state, but to make a clear
difference as a new concept, I think 'Continuation' is
accurate. But
'Web..'?!
- rename WebContinuation to Continuation, and accordingly
WebContinuationManager to ContinuationManager.
I guess I'm a little confused at the general agreement on
this naming
using continuation. I thought I was hearing in Sylvain's
original
RT that continuations may not be the only implementation. I don't
have a problem with any of the new names suggested which is why I'm
not really adding anything to the discussion at this point, but I
don't want to have the discussion miss this point.
Could someone who resonates with the vision for these other
potential
(non javascript-with-continuations) implementations of flow
comment on
this quickly? If it satisfies you, I have no personal objection.
A little example:
function myFunc()
{
x = bla;
sendPageAndWait(first)
if (answer = sucess)
y = blub;
sendPageAndWait(choice)
else
y = yagh;
sendPageAndWait(choice)
sendPageAndWait(last)
}
Here you have four different states:
state 0:
x = bla;
sendPage(first)
state 1:
y = blub;
sendPage(choice)
state 2:
y = yagh;
sendPage(choice)
state 3:
sendPage(last)
And several transitions:
state 0 - state 1 if answer = sucess
state 0 - state 2 otherwise
state 1 - state 3
state 2 - state 3
So, here we have a DFA.
The 'continuation' means to freeze the current state of the
execution. The benefit of the continuations are that you have
a history of the states, which you had traversed. And like a
backtracking algorithm, you can go back to a previous state
and follow another route.
So, the answer is, it is sufficient to have the 'history of
states' to take a new name like 'continuation' instead of
simple 'state'? I think yes.
Sorry, I don't think so. I'm not a specialist in Scheme but I think
there is a concept behind continuations and the general use for all
controllers in Cocoon would be misleading.
Reinhard
RE: [Vote] Controller/Sitemap integration
IMHO: I think the verb 'continue' catches a broader consensus: interactions or use cases are indeed just started(initiated) or continued, and this also captures the relation the sitemap has to this. The noun 'continuation' has gotten a ring of being tied to a interpreted-language implementation. The inflected confusion from the history of the 'noun' adds up to some case against using it IMHO. +1 Reinhard
RE: [Vote] Controller/Sitemap integration
So, here we have a DFA. The 'continuation' means to freeze the current state of the execution. The benefit of the continuations are that you have a history of the states, which you had traversed. And like a backtracking algorithm, you can go back to a previous state and follow another route. So, the answer is, it is sufficient to have the 'history of states' to take a new name like 'continuation' instead of simple 'state'? I think yes. Sorry, I don't think so. I'm not a specialist in Scheme but I think there is a concept behind continuations and the general use for all controllers in Cocoon would be misleading. Okay, to be sure I googled around, and found: http://www.cs.utexas.edu/users/wilson/schintro/schintro_141.html call-with-current-continuation call-with-current-continuation is a very powerful control construct, which can be used to create more conventional control constructs, like catch and throw in Lisp (or setjmp and longjmp in C), or coroutines, and many more. It is extremely powerful because it allows a program to manipulate its own control stack so that procedure calls and returns needn't follow the normal depth-first textual call ordering. Recall that we said [ WHERE? ] that Scheme's equivalent of an activation stack is really a chain of partial continuations (suspension records), and this chain is known as a full continuation. And since continuations are immutable, they usually form a tree reflecting the call graph (actually, only the non-tail calls). Normally, the parts of this tree that are not in the current continuation chain are garbage, and can be garbage collected. If you take a pointer to the current continuation, and put it in a live variable or data structure, however, then that continuation chain will remain live and not be garbage collected. That is, you can capture the current state of the stack. It is not exactly what I want, but the core statement is 'A continuation is chain of partial continuations, or captured states of the stack' I think :) But maybe I'm wrong?! It's funny, but the whole continuation concept reminds me of the Tomita algorithm for simulating a GLR parser, which I currently working on ;-) http://www.cs.rhul.ac.uk/research/languages/publications/tomita_style_1.ps Stephan.
RE: [Vote] Controller/Sitemap integration
From: Marc Portier [mailto:[EMAIL PROTECTED] Hi Mark, Good remarks! My list then becomes: Integrating the flow processor/engine: - V2 : flows/flow/(@type,@name)/* +1 Call a flow the first time: - V2 : initialize/(@flow,@type)/paramaters +1 Continue a flow: (just added the option) - V7 : continue/(@flow,@type)/paramaters +1 Component declaration: (indifferent on the engine-processor) +0 Renamings: - V1 : FlowState(and -Manager) I would leave the names as they are because as you (I think it was you) pointed out that this belongs to the implementation and not the interface. So I'm -0 on a renaming. Reinhard
Re: [Vote] Controller/Sitemap integration
Reinhard Pötz wrote: As I have been confused by all those suggestions you can find a summary here: http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration Cool summary, really helps a lot. And here the cool voting matrix :) | A | B | C | D | E | |---|---|---|---|---| | | | | | | V1 | -1 | +0 | +0 | +.5 | +1 | | | | | | | V2 | +1 | -1 | -0 | +.5 | -1 | | | | | | | V3 | ?? | +.5 | -1 | \ | \ | | | | | | | V4 | \ | -1 | -0 | \ | \ | | | | | | | V5 | \ | +1 | +.5 | \ | \ | | | | | | | V6 | \ | \ | -1 | \ | \ | | | | | | | V7 | \ | \ | +1 | \ | \ | | | | | | | |---|---|---|---|---| What is the difference between A V1 and A V2? Only the map:flows/? And what does it mean? B V5 was missing. From Marc's answer I guess he meant this, but chooses V1. Joerg
Re: [Vote] Controller/Sitemap integration
Reinhard Pötz wrote: From: Marc Portier [mailto:[EMAIL PROTECTED] Hi Mark, Good remarks! thx. snip / Renamings: - V1 : FlowState(and -Manager) I would leave the names as they are because as you (I think it was you) pointed out that this belongs to the implementation and not the interface. So I'm -0 on a renaming. Well, this in fact touches the very topic of why I think the map:continue flow=.. / could loose the need for a @type indication... if all the flow implementations would have their continuing stateful beasts implement the same interface (FlowState) then we get to have a higher level of reuse... (and more common stuff between different implementation, and more cross polination between their teams, and...) so what I really meant is that WebContinuation could continue to exist but then by implementing FlowState and as such be managed by the BasicFlowStateManager (the same Manager would then manage the stateful objects that can continue flows initiated by any engine/processor) also: implementing a FlowStateManager is IMHO about other concerns then how you instantiate them in their very nature (which is the job of the Engine/Processor) -- I'm planning some RT on those concerns in the near future, think to date I couldn't achieve a lot more then chaotic ramblings so the sepecific execution context these managed FlowState's need to perform their 'continue' action should be enclosed in the implementation (and thus hidden behind the interface) [NOTE: I'm using in aparent self-confident-mode a verb like 'should' but I reall am very much in dream-out-loud mode still, comments and feedback welcome, is this making sense?] Coming back on the vote: the issue here is not really about renaming these classes, but about introducing this FlowState abstraction layer. Your remark rightfully makes me see I was starting to overlook the subtle nuance. all in all, I have the feeling this is not really part of the public interface we want to nail down here and now ? (meaning that I believe the introduction of this layer could be done whithout much effect on applications that just use an certain flow implementation, of course the flowprocessor impl's themselves would have some refactoring ahead) the same remark probably goes for the FlowEngine/Processor and might explain our lesser natural connection to these issues on the table? Reinhard what do others think? -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
[Vote] Controller/Sitemap integration
After the balkanization discussion it's time to vote on this last point before we can release Cocoon 2.1 with stable public interfaces: Out of Sylvain's RT [http://archives.real-time.com/pipermail/cocoon-devel/2003-July/016291.h tml] So here are the proposed refactorings : 1/ In the flow classes. These changes will be totally transparent to both existing sitemaps and existing flow scripts. - rename Interpreter to FlowEngine, - rename WebContinuation to FlowState, and accordingly WebContinuationManager to FlowStateManager. 2/ In the sitemap language. These changes can be disruptive with existing sitemaps, but we can provide (although we aren't in beta) a compatibility mode : - rename map:call function= to map:call flow= or map:call controller= - rename map:call continuation= to map:call state= Compared with the last vote [http://archives.real-time.com/pipermail/cocoon-devel/2003-July/016879.h tml] following items have changed and we need to vote on them again: [A] The Cocoon Advanced Control Flow provides a controller that is linked into the sitemap (as **child element** of map:sitemap .../: map:flow type=[yourEngine] [configuration] /map:flow This reflects that the flow is not a *usual* sitemap resource but something else. [B] The controller is called by: map:call flow=[yourFlow] map:parameter name=x value=y/ /map:call [C] A state of the controller is called by: map:call state= map:parameter name=x value=y/ /map:call [D] All flow interpreters[3] are Avalon components and declared in the cocoon.xonf: flow-engine default=[yourController] logger=[yourLogger] ... /flow-engine [E] Changes in the current Javascript implementation: - rename Interpreter to FlowEngine, - rename WebContinuation to FlowState, and accordingly WebContinuationManager to FlowStateManager. Please cast your votes! Cheers, Reinhard PS: Probably I will not be able to count the votes and summarize the result as I'll be on vacation :-)
RE: [Vote] Controller/Sitemap integration
From: Reinhard Pötz [A] The Cocoon Advanced Control Flow provides a controller that is linked into the sitemap (as **child element** of map:sitemap .../: map:flow type=[yourEngine] [configuration] /map:flow This reflects that the flow is not a *usual* sitemap resource but something else. [B] The controller is called by: map:call flow=[yourFlow] map:parameter name=x value=y/ /map:call [C] A state of the controller is called by: map:call state= map:parameter name=x value=y/ /map:call [D] All flow interpreters[3] are Avalon components and declared in the cocoon.xonf: flow-engine default=[yourController] logger=[yourLogger] ... /flow-engine [E] Changes in the current Javascript implementation: - rename Interpreter to FlowEngine, - rename WebContinuation to FlowState, and accordingly WebContinuationManager to FlowStateManager. Please cast your votes! I'm +0 on all items. Cheers, Reinhard
Re: [Vote] Controller/Sitemap integration
I don't have a vote, but I have been somewhat connected to this
thread so I thought I'ld speek up anyway...
As for the proposal Sylvain and I uttered originally I would
consider the discussion we had on the topic after Sylvain's post
to direct more (but not completely) into the naming-proposals
Stephan is introducing here...
The following might seem like nagging but I do share Sylvain's
eagerness to get names really right, so I'm wide open for other
alternatives and views...
Stephan Michels wrote:
If I think on different implementations for the flow,
the names are not every intuitive, IHMO.
So, can I offer some alternatives?
On Wed, 16 Jul 2003, Reinhard Pötz wrote:
[A] The Cocoon Advanced Control Flow provides a controller that is
linked into the sitemap (as **child element** of map:sitemap
.../:
map:flow type=[yourEngine]
[configuration]
/map:flow
This reflects that the flow is not a *usual* sitemap resource but
something else.
The point, which irritates me, is that you don't have a identifier
to address the script/whatever.
So my favorite choise will be
map:flows
map:flow name=js type=javascript
script src=flow/PetStoreImpl.js/
script src=flow/petstore.js/
/map:flow
map:flow name=java type=atct class=org.apache.cocoon/
map:flow name=fsm type=fsm src=descriptors/fsm.xml/
/map:flows
So this will be coherent with the other objects.
and it makes perfect sense after the recent discussions
it does go a step further and assumes we allow for more then one
flow impl to be active at any given time
not needing to choose one impl for the complete cocoon webapp is
still something different then making sure that implementations
can be swapped (we had a consensus on the latter, not yet on the
first)
but again, it makes sense all the way and IMHO assures more
easily for a seemless integration of what is around (and thus
making sure more of the 'related' issues will be handled in equal
ways, making the different impl more 'alligning' then 'competing')
[B] The controller is called by:
map:call flow=[yourFlow]
map:parameter name=x value=y/
/map:call
Seems fine, an alternative will be
map:initiate flow=js call=[Javascript function]
map:parameter name=x value=y/
/map:initiate
map:initiate type=java call=[Java method]
map:parameter name=x value=y/
/map:call
map:initiate type=fsm call=[Name of state]
map:parameter name=x value=y/
/map:initiate
I like the combination of initiate/continue
yes, I stated this in another thread, looking at it from the POV
of the sitemap there are two kinds of URI's:
1/ the ones that start/initiate a use case (of which the state is
managed at the server side)
2/ the dynamic ones that point to states that can continue the
process
[C] A state of the controller is called by:
map:call state=
map:parameter name=x value=y/
/map:call
We don't call states in this sense. We continue
a continuation ;-)
actually I think we continue with the 'use-case'
or we continue the 'interaction'
I guess map:continue continuation={1}/ is bad.
map:continue src={1}/
or
map:continue id={1}/
Still map:continue state-id=.. / might make sense as well?
[D] All flow interpreters[3] are Avalon components and declared
in the cocoon.xonf:
flow-engine default=[yourController] logger=[yourLogger]
...
/flow-engine
+1, except the name, see next.
[E] Changes in the current Javascript implementation:
- rename Interpreter to FlowEngine,
Again, to be coherent my favorite is
flow-processor like xslt-processor and xpath-processor, or
treeprocessor.
quite indifferent here, since processor is still not catching it
completely IMHO, but I don't have a better alternative yet :-(
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Yes, the Continuation represents a state, but to make a clear
difference as a new concept, I think 'Continuation' is accurate.
But 'Web..'?!
I think there is two things here: interface and current
implementation.
we should get the correct name for the abstract thing, but the
WebContinuation could keep on existing as the
flow-script-js-continuation thingy that just implements that
(although some reference to js in that name would make more sense
then?)
I still like FlowState in this context... as I said above we
continue with the use case or interaction (rather then 'the
continuation')... the reason why we can do that is because there
is server side State of the Flow maintained for the current point
in that process...
(I know State sounds like something 'passive' while the
continue-responsibility it has points out some 'activity'... note
however that the Flow-prefix makes up for that, and that the
classic 'State' pattern suffers from the same, so some of us
might be used to it)
- rename WebContinuation to Continuation, and accordingly
WebContinuationManager to
RE: [Vote] Controller/Sitemap integration
Marc Portier wrote:
The following might seem like nagging but I do share Sylvain's
eagerness to get names really right, so I'm wide open for other
alternatives and views...
I don't have a vote either :-) but I agree - names are a very important detail, so
I'll stick my nose in...
[C] A state of the controller is called by:
map:call state=
map:parameter name=x value=y/
/map:call
We don't call states in this sense. We continue
a continuation ;-)
actually I think we continue with the 'use-case'
or we continue the 'interaction'
I guess map:continue continuation={1}/ is bad.
map:continue src={1}/
or
map:continue id={1}/
Still map:continue state-id=.. / might make sense as well?
What about map:continue from=.../
I agree with your analysis completely ... personally I find map:continue with
attribute of id or source or state sounds jarring - it sounds like you would be
continuing a state, or continuing an id, which is wrong, as you say. It doesn't read
smoothly in the sense of a regular English sentence, whereas continue from ... reads
very naturally.
The point is that you continue a FLOW (a use-case as you say), and that you continue
the flow FROM a particular point which must be identified by this attribute.
Continue is the active (verb form) word which identifies the activity (noun form
would be continuation). From is a word that identifies the role that the
rhino-continuation or FSM-state plays in this activity, without having to give it some
overly-specific name (state, continuation, location, point, etc)
My 2c
Con
