News for hackers. Stuff that matters.
Re:Eventual Consistency in Real-time Web Apps by aidos on Tuesday June 17, 2014 @11:15AM (#7904877)
That's great information, thank you. The paper looks really interesting - going to take a little while to get through, might start with the video :)

I'd also read that it's hard to get right (I think that was in a comment on HN by one of the people who worked on wave/sharejs). In my case I've limited myself to two different flavours of small object with a limited set of fields (instead of a totally generalised system). Most of the algorithms I've seen focus on the text element of the syncing but I'm much more interested in the object / list / field part for my use case.

Sharejs actually have a generic system of handling the OT on arbitrary json structures, but I'm not sure how well it works.

Re:Eventual Consistency in Real-time Web Apps by dahjelle on Tuesday June 17, 2014 @12:10PM (#7905216)
I've not tried it, but you might also be interested in an approach called differential synchronization[1]. Basically, it's just a specific way of passing diffs around to guarantee convergence, though (as far as I can tell) it doesn't guarantee much else (as in do you lose data if a patch can't be applied?). The really nice bits, though, are that it is a simple algorithm and that it can be applied to anything that you have diff/patch algorithms for.

[1] https://www.youtube.com/watch?v=S2Hp_1jqpY8

Re:Eventual Consistency in Real-time Web Apps by aidos on Tuesday June 17, 2014 @03:57PM (#7906612)
I already watched that video the other day! Didn't quite get to the end of it but I thought the general idea was interesting.

My use case is a little different, and one that OT seems to suit.

I have multiple users working on the same documents but they don't want/need to see each other's changes straight away. They perform a number of operations and then eventually save. When they save I'd like to propagate that that history to the other user(s) that haven't saved yet. It feels like OT works there - you have two threads of history and you need to rebase the uncommitted one on top of committed one.

Maybe I'm coming at the problem wrong, but it feels like something that could work quite well as a pattern in general.