search

Andrei486 / uml-diagram-collab

0 stars 0 forks source link

Investigate master copy of diagram - second reader feedback #75

Closed Andrei486 closed 9 months ago

Andrei486 commented 9 months ago

Like the second reader said in the presentation, it would be nice to have a blanket solution to avoid desyncs.

One possible way would be to make tracked commands not actually execute on the client, but only send to the host. The host would then execute the command on itself and relay to all clients, even the one that sent the update. This effectively makes clients request updates instead of performing them, TrackedCommand would change to more of a CommandRequest.

em66850 commented 9 months ago

This sounds like a good solution, but on a slower network clients may think the app is glitching and it would result in bad user experience. I think we could add something UI wise to make it clear to the user that their action did go through while still using this solution. Here's one idea I had: we could make a copy of the original element on the clients end, apply the command to that element, set the original to transparent (but it would still exist), and then send the command to the host. When the host approves it, the client applies the command to the original element, deletes the duplicate, and then makes it visible again. It would look seamless on the clients end while still having the host approve all commands. If the host denies it, the duplicate would just need to be deleted and the original would be made visible again. The issue with this is if the client makes a change to the duplicate element it would either be ignored (which in some cases is necessary) or we'd have to implement some way of sending the original's ID in the command to the host. It also isn't great UX if the user watches their change be undone, but I think it's better than the alternative, especially because changes should not be denied very often. We should talk about this issue as a team to find the best solution.

Andrei486 commented 9 months ago

Tested locally with 3 people. The only impact is on clients who take a bit of time to see their own changes. On a local network this is well below the allowable 0.5s but we will test on a VPN.

Andrei486 commented 9 months ago

Implemented the original idea (no rollback yet) on a test branch: see PR #77.

vpn_performance.txt The above data was obtained when using a VPN to connect from three separate networks. The time between a client sending a command to the host and receiving + executing the command was around 0.2 to 0.25s, which is visible latency but within requirements. Other interactions (host/client for example) will not be affected. More statistical analysis can be performed using that data.