You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2006/01/18 17:22:06 UTC
DO NOT REPLY [Bug 38311] New: - [scxml] explore strategies for decoupling execution context from representation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
Summary: [scxml] explore strategies for decoupling execution
context from representation
Product: Commons
Version: unspecified
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Sandbox
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: tobrien@discursive.com
The current model of a state machine contains references to the context and the
notification registry. We need to figure out a strategy for decoupling state
machine representation from the executor so that we can have multiple instances
of a state machine that use the same model.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
rahul@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|Sandbox |SCXML
------- Additional Comments From rahul@apache.org 2006-04-20 21:45 -------
Re-assigning from Sandbox to SCXML.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
rahul@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |38276
nThis| |
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
------- Additional Comments From rahul@apache.org 2006-02-03 23:24 -------
(In reply to comment #6)
> +1 for anything *Instance. ExecutionData seems overly vauge. Evnironment as
> well, but instance seems like a valid concept.
>
> So, in some Voice response system that might use SCXML to handle multiple
> conversations at once, one could say that there is one SCXML object that
models
> states, etc. and multiple [ExecInstance|SCInstance|MachineInstance] whatever
>
Yes, that is how I see it as well.
> I'm also convinced that the value was this conversation, and that if you
decided
> to call is "SuperMagicStateObject", we'd at least be able to refer someone to
> this Bugzilla thread to get context.
Indeed, this has been very useful, thanks for your comments. I'll follow up in
code over the next day or two.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
rahul@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |38275
nThis| |
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
rahul@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
------- Additional Comments From rahul@apache.org 2006-01-29 19:48 -------
Thanks for highlighting the issue. A proposed solution is available in the
STATELESS_MODEL branch. Comments welcome. If there are no comments in a few
days, I intend to merge changes to trunk.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
------- Additional Comments From tobrien@discursive.com 2006-02-03 20:30 -------
Here's where I find the naming confusing. Imagine the documentation for this:
"A state machine is modeled by an instance of SCXML which contains all the
states and transitions that describe the structure and features of a state
machine. When an application needs to execute such a state machine, it will
need to provide a Registry. The Registry contains contexts, historical state,
and listeners that are notified when certain events occur during the execution
(or interpretation) of a state machine. This Registry also contains an object
named NotificationRegistry which is a registry of the aforementioned listeners."
So the thing I'm seeing is that the concept of the NotificationRegistry being a
registry of listeners within a larger registry (which is more of an
ExecutionEnvironment) seems confusing.
It also stems from the fact that a "Registry" is usually an object than contains
a collection of similar elements. So, a PersonRegistry contains people, a
ListenerRegistry contains listeners, etc. Calling the execution environment a
registry just strikes me as a misnomer because it holds a collection of
different elements all important to execution.
Anyway, I know I'm being a stickler for the details, but I think of language and
terminology as something that needs to be addresses up front. I can understand
that a larger "ExecutionContext" contains a number of objects necessary for
execution including a sub-contexts that store information particular to each
state. I feel less comfortable explaining that the "Registry" contains a series
of objects necessary for execution including a NotificationRegistry and a series
of a Content objects and histories.
In addition, having a class named "Registry" and a class named
"NotificationRegistry" implies an extension or implementation relationship.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
------- Additional Comments From rahul@apache.org 2006-02-03 19:46 -------
(In reply to comment #2)
> You've removed the Context from State and now SCXMLSemanticImpl grabs the
> context from the notification registry. The only quesion issue I've got is
that
> Registry is awfully close to NotificationRegistry and might the two become
> confused.
<snip/>
Possibly, just as it got confused above, or maybe it was a typo. The Contexts
are obtained from the Registry (not the NotificationRegistry). The Registry
keeps the books for a particular state machine execution instance, and
maintaining notification listeners is but one aspect of that function.
In totality, the current "registry" keeps record of:
1) The contexts created, and the states they were assigned to
2) The last known configurations for the histories
3) The root context and the expression evaluator
4) The SCXMLListeners attached to the interesting nodes in the SCXML object
model (via the NotificationRegistry)
The NotificationRegistry is a convenience class for (4) at this time, rather
than inlining all its methods in the Registry class -- but the separation of
concerns is useful and also improves source readability, IMO. Also, as the
specification matures, it is quite possible that there will be more things
to "track".
And maybe your comment above had a typo, which makes this explanation
unnecessary.
> Is there a better name for the Registry class, maybe something like
> "Execution" or "ExecutionEnvironment", or "ExecuteContext"
> ....or "SuperFancyStateMachineExecutionUtil"
> And, I know this is nit picky, so feel free to object strenuously.
Since Execution is somewhat vague and Context is already an SCXML interface,
probably the only suggestion worth considering from the list above is
ExecutionEnvironment. But even so, I tend to favor Registry because IMO it is
closest to summarizing what the class is actually doing (I think of the
execution environment as the system the state machine is controlling). I'll be
merging the STATELESS_MODEL branch to trunk over the weekend, but we can
always change the name even after the merge, if it remains a concern.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
rahul@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
------- Additional Comments From rahul@apache.org 2006-02-05 17:55 -------
I have renamed the Registry class to SCInstance, and the STATELESS_MODEL
branch has been merged with trunk in r375053. The changes discussed here are
now in trunk and therefore, I am closing this as FIXED.
The documentation (Javadocs and xdocs/) has been minimally updated, further
improvements are necessary. However, those improvements have been assigned to
separate issues in Bugzilla (see the list of bugs blocked by this one).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
------- Additional Comments From rahul@apache.org 2006-02-03 21:45 -------
Earlier post re-arranged in response:
(In reply to comment #4)
> In addition, having a class named "Registry" and a class named
> "NotificationRegistry" implies an extension or implementation relationship.
I think this implied relationship based on the names is a convincing argument
for changing the name (it is a HAS-A rather than IS-A relationship, so the
current names are ill-suited).
> Here's where I find the naming confusing. Imagine the documentation for
this:
> "A state machine is modeled by an instance of SCXML which contains all the
> states and transitions that describe the structure and features of a state
> machine. When an application needs to execute such a state machine, it will
> need to provide a Registry. The Registry contains contexts, historical
state,
> and listeners that are notified when certain events occur during the
execution
> (or interpretation) of a state machine. This Registry also contains an
object
> named NotificationRegistry which is a registry of the aforementioned
listeners."
Even leaving aside the confusion implied by the naming, the above
documentation would simply be incorrect. The "Registry" (or whatever the new
name is, for the sake of this note I'll continue to call it that) is an
internal structure to the SCXMLExecutor, and the developer/application does
not need to "provide a Registry" (just a limited number of its parts directly
via the SCXMLExecutor class API).
See the, albeit incomplete, documentation here:
http://people.apache.org/~rahul/sites/scxml-stateless-model/api-notes/core-
engine.html
The developer provides only the root context, expression evaluator and any
listeners. The developer does not need to instantiate a Registry and does not
need to deal with (or be concerned about) the contexts per state or the
histories (they get assigned and populated by the Registry).
> Anyway, I know I'm being a stickler for the details, but I think of language
and
> terminology as something that needs to be addresses up front.
This is good for the Commons SCXML component, do continue to be a stickler.
> I can understand
> that a larger "ExecutionContext" contains a number of objects necessary for
> execution including a sub-contexts that store information particular to each
> state. I feel less comfortable explaining that the "Registry" contains a
series
> of objects necessary for execution including a NotificationRegistry and a
series
> of a Content objects and histories.
But does ExecutionContext have potential for the same confusion w.r.t the
Context interface, as NotificationRegistry had with Registry? That was my
brief reference in comment #3.
Suggestions for name:
* ExecutionContext (pending question above)
* ExecutionEnvironment (suggestion from comment #2)
* ExecutionData
* ExecutionInstance
* --something else--
WDYT?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
------- Additional Comments From tobrien@discursive.com 2006-02-03 23:03 -------
(In reply to comment #5)
> Even leaving aside the confusion implied by the naming, the above
> documentation would simply be incorrect. The "Registry" (or whatever the new
> name is, for the sake of this note I'll continue to call it that) is an
> internal structure to the SCXMLExecutor, and the developer/application does
> not need to "provide a Registry" (just a limited number of its parts directly
> via the SCXMLExecutor class API).
>
OK, then ignore the interpretation. Apologies for the misread.
> But does ExecutionContext have potential for the same confusion w.r.t the
> Context interface, as NotificationRegistry had with Registry? That was my
> brief reference in comment #3.
>
> Suggestions for name:
>
> * ExecutionContext (pending question above)
> * ExecutionEnvironment (suggestion from comment #2)
> * ExecutionData
> * ExecutionInstance
> * --something else--
+1 for anything *Instance. ExecutionData seems overly vauge. Evnironment as
well, but instance seems like a valid concept.
So, in some Voice response system that might use SCXML to handle multiple
conversations at once, one could say that there is one SCXML object that models
states, etc. and multiple [ExecInstance|SCInstance|MachineInstance] whatever
I'm also convinced that the value was this conversation, and that if you decided
to call is "SuperMagicStateObject", we'd at least be able to refer someone to
this Bugzilla thread to get context. So, consider views aired, but don't hold
off on merging or committing.
>
> WDYT?
>
>
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 38311] - [scxml] explore strategies for decoupling execution context from representation
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38311>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
------- Additional Comments From tobrien@discursive.com 2006-02-03 10:49 -------
You've removed the Context from State and now SCXMLSemanticImpl grabs the
context from the notification registry. The only quesion issue I've got is that
Registry is awfully close to NotificationRegistry and might the two become
confused. Is there a better name for the Registry class, maybe something like
"Execution" or "ExecutionEnvironment", or "ExecuteContext"
....or "SuperFancyStateMachineExecutionUtil"
And, I know this is nit picky, so feel free to object strenuously.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org