Re: Synchronizing Data Models

I have opened an issue in our "Future Version of SCXML" bin to keep 
track of this.  At first glance, the fundamental issue is still having a 
data model that can be modified by an external entity.  For example, if 
we have one-way synchronization from machine A to machine B, then from 
machine B's point of view, machine A is the external entity.  If we have 
two-way synchronization, then each machine is an external entity to the 
other.  I think that it would be relatively easy to define a datamodel 
that published its changes to an external target (note that invoked 
state machines  do this already via <finalize>).  The trick is how to 
notify the target state machine when its datamodel changes (since a new 
set of transitions may now be enabled.)

In general, we can think of datamodel synchronization as pub + sub for 
changes.  On the whole, I think that there are good use cases for state 
machines with these capabilities.  We certainly will discuss this if we 
decide to do SCXML++.  Pub is easy... sub not so much.


- Jim
On 6/18/2014 9:45 AM, Gavin Kistner wrote:
> 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?
>
>
>

-- 
Jim Barnett
Genesys

Received on Monday, 23 June 2014 13:55:26 UTC