I have started this blog for SCION news and updates because I wanted to provide a fuller picture of the major architectural changes that are occurring in SCION, and the motivation for making these changes. I’ll refer to this next major iteration of SCION as “SCION-ng” (for “next generation”), although the branch name on GitHub is “core”, and the semantic versioning number has been rev’d to 1.0.0, so it could be referred to by any of these attributes.
Deficiences in SCION
So far, I think the SCION project has been successful in reaching its initial goals of developing a fast, robust, portable, embeddable SCXML interpreter. SCION is being used in production and provides an effective solution for many developers working with SCXML.
Solution and Benefits
There will be additional benefits to this refactoring effort as well:
- It will be possible to entirely eliminate SCION’s somewhat brittle DOM compatibility layer, which should mean greater reliability across environments.
- Stripping SCION-core down to just the state machine interpreter made it feasible to combine everything into one UMD module (it’s under 1000 LOC, including comments, which I think is quite reasonable for a single module). This means it will be trivial to install and use SCION from CommonJS, AMD, or Vanilla JS - no build step or compatibility shims required! It also means that Google Closure compiler can optimize things really well, leading to the next point…
- SCION-core is super-small - only 2.3kb after being minified and gzipped! This will give Web developers a lot of expressive power in a very tiny package.
So, that’s a lot of talk about architecture, let’s look at some code. All of these examples have been auto-generated by scxml.js from the scxml-test-framework, so they are not the most user-friendly, but should give you a sense of how to specify Statecharts models for SCION-core, and the compiled code output of scxml.js.
Here’s an example based on test basic/basic1.scxml:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
As you can see, it’s just a simple JSON file. This can be passed directly into the SCION constructor like so:
1 2 3
Here’s an example compiled from test script/test0.scxml that shows how to execute actions and manipulate data:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
You could use this model as follows:
1 2 3
More examples can be found in the tests directory of the “core” branch of SCION.
Documentation still needs to be written for SCION-core, but it passes all the tests from the scxml-test-framework, and so I feel it is ready to be used. It exists as a single UMD module here, in the “core” branch of SCION.
scxml.js still needs some more work: it currently only supports ahead-of-time compilation using node.js, so I need to make it portable and support on-the-fly compilation. The code lives here.
I’m planning to continue working in the “core” branch of SCION until scxml.js is fully compatible with the current SCION API. When that’s done, I’ll publish a final release of the SCION 0.0.* branch. I’ll then merge the SCION “core” branch back into “master”, and publish a 1.0.0 release of SCION-ng.
I welcome your questions and comments.