In realtime collaboration, peers might be momentarily disconnected. With current realtime collaboration APIs of Apollon, when they reconnect, they will start receiving the remainder of the updates, not noticing the disconnection at all, but also not receiving changes they have missed.
Implementors of realtime collaboration can of course implement mechanisms to ensure each client WILL receive all updates with some temporal ordering so that they also converge, but this can be particularly difficult for them, going against the ideal of having an extremely easy-to-implement realtime collaboration system with Apollon.
Describe the solution you'd like
Ideally, Apollon could provide APIs for also syncing the diagram wholesale without affecting client-side changes that are not synced yet, and hopefully in a way that doesn't result in stuttering with mis-ordering of Apollon patch messages. Realtime collaboration already assumes some global ordering of patches, so such "sync" messages can also be timed properly with those messages via implementors (for example, on the server side). Alternatively, timestamps can be put on sync messages and patches, so that out-of-sync patches or sync messages do not get applied locally.
Describe alternatives you've considered
An alternative is to have implementations of realtime collaboration to repeat messages until they get some sort of acknowledgement. They could also limit this to discrete changes for efficiency, but would also need to implement some form of out-of-order message handling then, which further complicates implementation of realtime collaboration with Apollon.
Is your feature request related to a problem?
In realtime collaboration, peers might be momentarily disconnected. With current realtime collaboration APIs of Apollon, when they reconnect, they will start receiving the remainder of the updates, not noticing the disconnection at all, but also not receiving changes they have missed.
Implementors of realtime collaboration can of course implement mechanisms to ensure each client WILL receive all updates with some temporal ordering so that they also converge, but this can be particularly difficult for them, going against the ideal of having an extremely easy-to-implement realtime collaboration system with Apollon.
Describe the solution you'd like
Ideally, Apollon could provide APIs for also syncing the diagram wholesale without affecting client-side changes that are not synced yet, and hopefully in a way that doesn't result in stuttering with mis-ordering of Apollon patch messages. Realtime collaboration already assumes some global ordering of patches, so such "sync" messages can also be timed properly with those messages via implementors (for example, on the server side). Alternatively, timestamps can be put on sync messages and patches, so that out-of-sync patches or sync messages do not get applied locally.
Describe alternatives you've considered
An alternative is to have implementations of realtime collaboration to repeat messages until they get some sort of acknowledgement. They could also limit this to discrete changes for efficiency, but would also need to implement some form of out-of-order message handling then, which further complicates implementation of realtime collaboration with Apollon.