Tiny Update - Slight Architecture Change
by adam
I just spent quite a few hours this weekend making some changes to the Listotron code-base.
The Problem
The browser polls the server many many times a second, and the server sends back whatever’s changed in that small amount of time. This means that if an AJAX call is taking about 100ms, then the change 1 user makes to the list will show up on all other collaborators screens after no more than 200ms. Pretty sweet!
So I had all of that working a few weeks ago - multi-user list collaboration and all - but I found that sometimes collaborators lists got out of sync. Not all of the edits seemed to make their way across all collaborators.
The problem: I was doing all of the data manipulation in JavaScript in the browser, and only sending the changes to the server. So when a user indented a line in the list, instead of sending an “indent” command to the server, I would indent locally and send the updated row’s properties to the server.
The problem was further compounded by the fact that 1 edit (that should have been atomic) was split into multiple AJAX calls (due to how BAJAX bundles sets of ajax requests).
The problem manifests itself when 2 people edit the exact same row at the exact same time (not that uncommon in my 6 row demo list). Each user’s JavaScript would update the row differently and send their own results to the server. Each time, the server would accept the changes, modify the server’s definition of the list, and send back an “ok!” So both user’s got a successful response but saw totally different lists.
The Solution
The solution is to do all list manipulation on the server. so instead of sending a row’s updated properties (like who the parent row is and what row is before it), i just send a specific and atomic command, like “indent row X.”
The server then indents the row if it can, and returns a list of all modified rows to the client. Then the client updates the view. This means that currently the view takes about 150-200ms for a keypress to manifest itself in the view.
This delay will fixed in later versions, and is surprisingly unnoticeable anyways.