[
https://issues.apache.org/jira/browse/SCXML-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma updated SCXML-196:
----------------------------
Comment: was deleted
(was: Ugh, above initial plan already starts breaking down :(
Keeping the existing implementation (SCXMLExecutor and SCXMSemanticsImpl)
working while starting refactoring the initialScript (to be renamed to
globalScript) handling is already too much complicated and invasive for the
existing implementation to be reasonable to retain both implementations
side-by-side.
So, I will drop this plan as well as the new SCXMLExecutor2 and
SCXMLSemanticsImpl2 classes, and instead start hacking directly on the existing
implementation.
This means it will be impossible, within the same codebase, to check and
compare the old against the new semantics, but so be it.
The milestone 0 tag at least is available to code compare against, and the
current, and for sure needed additional, unit tests to validate against.
This also means the current trunk will undergo a lot more immediately changes
as of now! )
> Redefine SCXMLSemantics to align with the Algorithm for SCXML Interpretation
> as described in the SCXML specification
> --------------------------------------------------------------------------------------------------------------------
>
> Key: SCXML-196
> URL: https://issues.apache.org/jira/browse/SCXML-196
> Project: Commons SCXML
> Issue Type: New Feature
> Affects Versions: 2.0
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.0
>
>
> One of the targets for the Commons SCXM 2.0 roadmap milestone 1 is to
> redefine SCXMLSemantics to align with the SCXML Algorithm for SCXML
> Interpretation, see:
> http://www.w3.org/TR/scxml/#AlgorithmforSCXMLInterpretation
> The current SCXMLSemantics interface and its implementation is so much
> different from the algorithm in the specification that 'molding' it into what
> the algorithm now expects is too cumbersome.
> The high-level plan I have is to:
> - fork SCXMLSemanticsImpl to SCXMLSemanticsImpl2, without implementing
> SCXMLSemantics
> - fork SCXMLExecutor to SCXMLExecutor2, extending SCXMLExecutor
> - switch to use SCXMLSemanticsImpl2 explicitly in SCXMLExecutor2
> - start with simply implementing the SCXML Algorithm from 'scratch' in
> SCXMLSemanticsImpl2 using (top level) methods matching those described in the
> algorithm and refactor SCXMLExecutor2 to leverage this
> With the above initial steps, the existing implementation will stay in place
> and remains available to compare and test the new implementation against.
> There probably will be need to make accommodating changes in other areas,
> which I will try to keep compatible with the existing implementation or at
> least not to break it.
> The reason to fork and extend SCXMLExecutor is that it is referenced and used
> in many other places (that is: currently), like in SCInstance. By extending
> it, the SCXMLExecutor2 can still play that role without directly breaking
> everything.
> The algorithm described in the specification leaves plenty of room for
> optimization and choice of techniques.
> For a first cut implementation though I intend to simply follow the described
> algorithm as close as possible, also to make sure not to deviate from the
> specification already too early :)
> After the new implementation has been tested and validated to be comforming
> the expected behavior, or even later than that, the implementation surely can
> be refined and optimized further.
> That also will be time to decide to drop and replace the existing
> SCXMLExecutor and SCXMLSemantics (both interface and implementation) with the
> new versions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
