Being able to focus efforts all in one place is certainly a positive. Seeing a statechart framework already in SproutCore and an external statechart framework like Ki may confuse people about what solution to go with, especially those newer to SproutCore. Perhaps I can shed some more light on Ki and the statechart framework that currently comes with SproutCore.

The statechart framework that comes with SproutCore certainly allows for state hierarchies and grouping of states within states. In addition, the framework also supports top-level state concurrency (state independence). These concepts are part of what you see in David Harel's statechart paper. And, of course, you are able to send events to the statechart that all of its current states can react to. That being said, there are some limitations.

A primary limitation is that you can't nest concurrent states within states in a statechart. This may not sound like much, but it becomes immediately apparent for large applications that have many features or modules, each that may require their own concurrent states. In order to get around this limitation you have to create new statecharts to represent nested concurrent states. Also, since those statecharts are separate entities, events sent to the main statechart are not implicitly propagated to other statecharts. You essentially have to make your own code to pass events along, which leads to inconsistent and extra code to maintain in addition to being error prone. Then there is the matter of just how enter and exit all those sub concurrent states -- Eek.

Apart from not being able to nest concurrent states within states, the statechart framewok in SproutCore also does not support the ability to perform asynchronous actions during a state transition process (going from one state to another state), meaning you can't do things like animations when entering and exiting states. The framework also requires that all states that are part of the statechart must have unique names, which can be cumbersome to keep track of when you have a large number of states in your statechart. Finally, the framework also limits your ability to reuse states (refered to as overlapping states in Harel's paper).

Ki was built up in order to address each of the these limitations and provide one simple, cohesive solution. But again, I did begin with the intent of trying to rework and update SproutCore's current statechart framework; however, given the differences and the way Ki needed to be implemented, it just turned out to be easier to start with a clean slate.

Mike

On Sep 8, 1:41 am, Peter Wagenet <pete...@gmail.com> wrote: