Event Propagation

[KevinMackenzie]

Right now the first draft of this system is done. It is tightly integrated into the ViewModel, however is generic enough to be completely handled in the ViewModelBase class in most cases.

To prevent back and forth propagation, one device must be the host and that device is the only device which is allowed to send data to the clients. All of the other clients are only allowed to send requests to the host. This host will typically be the robot, but there is no reason why it couldn't be the driver station. This must be implemented such that any web requests modify the data in such a way that the change does not cause propagation back to the host. On the host-side, a variable describing the sender of the request will exists so the request does not get propagated back to the sender.

Another issue with this that will come up is how to list-delete handlers. Right now only a change is seen through the propagation. One option is to check if an item exists at that location and if none does, then a deletion occurred.

The only option for HTTP verbs in the propagation is the PUT verb, because it ignores whether the item exists or not and just creates it. This does work well with the current architecture of CompoundProviderList

[KevinMackenzie]

The propagation itself is tested and does work as expected, however it is not currently hooked up to anything useful

[KevinMackenzie]

This is hooked up to the WebHooks system right now and works as expected/desired, but is pending more testing

[KevinMackenzie]

There is currently no protection from sending a request back to the sender; this needs to be added

[KevinMackenzie]

with the client -server paradigm being used in the new socket connections, this still a problem with perpetual updates.

[KevinMackenzie]

this has been heavily modified, therefore is partially obsolete.