Synchronizing Data Models

With an eye towards a future SCXML specification (or perhaps a parallel specification) I wanted to open a discussion on synchronization of data models (or subsets) between state machines. Is it desirable? If so, what should be standardized around it?

Consider a multi-display environment, such as both the digital in-vehicle instrument cluster along with the center console display. We want to synchronize certain data between these displays. For example, the song currently playing, the miles traveled on this trip, whether any song is currently playing, the album/artist/song/etc. of the currently-playing song, etc.

Some of this data is necessary in the state machine data model (and not just in the View) in order to control the state machine. For example, whether or not a song is playing may change an active state, or be a condition that guards a transition.

Some of this data is should clearly (I think) be stored in a 3rd system. For example, neither the cluster nor the console display applications are in charge of how many miles have been traveled on the trip. Neither application should ‘own’ this data. Instead, they should be consuming this data from a common source.

I *think* that there exists some data that logically belongs to one application or the other. (I am failing to come up with compelling example at the moment. Let’s say that the play/pause state is such data, though it is not.) If such data exists, it seems to be undesirable to publish this data to a 3rd party and having both applications subscribe to it. Instead, it would make sense to me that changes to a portion of the data model in one application should cause a mirrored change in the other application.

Such mirroring could be either unidirectional (a master/slave, publish/subscribe model) or bidirectional (a synchronized data model portion, where changes in either side are reflected on the other).


First: Does synchronizing values between data models sound useful and desirable to anyone else?

It is something that I am doing currently. However, upon reflection I am doing this only because during development it is easier to have an application simulate the 3rd party instead of implementing a mock 3rd party. And then, when second (and third) applications are added, synchronization seems like the simplest solution.


Second: If desirable, what is needed?

I think that it we would want this synchronization:

* limited to specific portions of the data model (either opt-in or perhaps opt-out). I think that this may be nearly mandatory.
* able to specify wildcards for synchronization (with hierarchical data structures, either synchronize just one child property, or synchronize all children, or all descendants).
* supporting unidirectional synchronization (one publisher, many subscribers).
* supporting bidirectional synchronization (ideally with many participants).
* to use some sort of communication abstraction, allowing different protocols/media.
* to be performant and lightweight: no (or limited) chatter when no changes have occurred, minimal communication bandwidth.

My current implementation for this is a serious hack. I do not have any data-set callbacks available, since in a Lua (or ECMAScript) data model <script>foo={}; foo.bar = 42</script> will set a child value inside a container object with no way to track future changes within it. As such, every frame (60Hz) I serialize every watched value and then compare it to the last-serialized value. Changed values are sent over a socket (requiring one of the applications to be blessed as a master, the rest as clients).


At EICS2014 Jim mentioned possibly adding some sort of registration for a callback when data model values are set. As shown above, having synchronization of specific child elements inside arbitrary data hierarchies may heavily complicate this.


Thoughts?

Received on Wednesday, 18 June 2014 13:46:17 UTC