Sim/gui shared state: brainstorm for a robust solution

[jooste]

In the ui-updates branch, I'm getting pretty close to enabling gui plugins. I think it's quite likely that the possibility of gui plugins will also lead to pairs of sim and gui plugins that belong together, and might also have a need for a shared state.

The current implementation of BlueSky already has parts where state is shared between sim and gui: the screenio object on the sim side keeps track of things like pan and zoom per client, and on the client side, GuiClient/NodeData keeps track of things like aircraft state per simulation node. This current implementation is however not very suitable for plugin shared states, as each added state would require also an edit of screenio.py and/or guiclient.py.

There are currently several types of such 'state-like' shared data between sim and gui:

• transient states (e.g., aircraft states). They are periodically transmitted, and are always completely replaced with each new received state

• persistent states (e.g., area definitions). These data are only sent on creation, modification, or deletion, or upon request (e.g., when a new client requests the entire simulation state to initialise its local data)

  • Some persistent states can vary often, at a high rate, for a short time, such as pan/zoom on the client side, when the user is pinching or swiping. Obviously such data shouldn't be sent at that rate to the sim. Currently pan/zoom is updated locally in the shared state NodeData object at this high rate, but an update to the sim is only sent when the pan/zoom gesture stops.

• 'selection' data (e.g., a route selected by the client).

• There might be more :)

My ideas to approach this so far is to make something similar to the with self.settrafarrays() syntax to create aircraft states. This would work at least for periodically updated shared states like aircraft state data. Both on the sim side and the gui side there would be some kind of singleton SharedState object, that can be used to access (I/O) the shared state data.

This concept is not yet complete, and I'm also not sure that I'm not overlooking flaws in this approach, so suggestions and comments are welcome!