| You couldn't be more wrong. Yes, websockets would make this easier and more seamless than (say) polling, but the "big deal" is that your entire model changes from: - There's a source of truth (server) and a single client at a time, ever. To: - There can be up to hundreds of clients at the same time, all having write access to the same data. Meaning: - Your old fashioned models don't quite cut it - you need something to handle changes happening locally [having to be propagated to the server/network ("committed") and potentially be rejected or changed], and at the same time receive remote updates, apply them to the local objects. - You're going to have conflicting writes. You don't want to have global locking in such a system, no matter how fine-grained (cell, in this case, I suppose); enter: Merge conflict resolution code (you'll have fun with that). Does it happen on the server? Client? How are conflicting writes resolved? Can the client handle just about any write having to be cancelled, and instead accept another change to the object? - Saving history states for all (ok, most) of your data, so that things can be rolled back. Kind of necessary when you can have a spreadsheet shared by 100 people, and any of them could delete the entire thing. Do these features ring a bell? Yes, we're talking about a distributed version control system here, but "you just saying" that all it is, is bidirectional communication? That's why you're being downvoted. |