3 ms·

Can any one who's looked at event sourcing comment on the relationship between ES (which is basically a fold over a sequence of events onto a state object) and

Can any one who's looked at event sourcing comment on the relationship between ES (which is basically a fold over a sequence of events onto a state object) and OT. Superficially it would seem that they are very similar, with OT perhaps being a way to combine the events before applying them to the state. The reason I ask is that I'm thinking of the feasibility of modelling a disconnected client that continues working from some state. Could you think of this as collecting its list of edits and then applying them on top of the state of the world when that client re-connects (sort of like a git rebase)?

dnr 13y ago
I've been working on a real-time collaborative app that does just that: the client collects a list of edits and tries to push them to the server. It always displays the state as the last known accepted state with the local edits replayed on top. The server accepts edits from clients, gives them a total order, and rebroadcasts them. It's intended to be used while connected, but the protocol has no problem dealing with arbitrary gaps in connectedness, so adding an official disconnected mode would be trivial. Importantly, "edits" here are discrete and independent. They can conflict (in which case it just does last one wins), but they can't affect the meaning of other edits. This scheme couldn't be used for collaborative editing of a linear text document, since e.g. "insert 'a' at position 15" means something different depending on whether it comes before or after "delete positions 5-10". That problem is what OT solves (by the transform function that lets you commute edits while preserving their meaning). So, yes, that kind of scheme is much simpler than OT, but less powerful. Whether you can use it depends on the semantics of your edits.

3 ms·

Can any one who's looked at event sourcing comment on the relationship between ES (which is basically a fold over a sequence of events onto a state object) and

by boothead 13y ago

dnr 13y ago
I've been working on a real-time collaborative app that does just that: the client collects a list of edits and tries to push them to the server. It always displays the state as the last known accepted state with the local edits replayed on top. The server accepts edits from clients, gives them a total order, and rebroadcasts them. It's intended to be used while connected, but the protocol has no problem dealing with arbitrary gaps in connectedness, so adding an official disconnected mode would be trivial. Importantly, "edits" here are discrete and independent. They can conflict (in which case it just does last one wins), but they can't affect the meaning of other edits. This scheme couldn't be used for collaborative editing of a linear text document, since e.g. "insert 'a' at position 15" means something different depending on whether it comes before or after "delete positions 5-10". That problem is what OT solves (by the transform function that lets you commute edits while preserving their meaning). So, yes, that kind of scheme is much simpler than OT, but less powerful. Whether you can use it depends on the semantics of your edits.