3 ms·

Repeatedly rewriting operations in-flight is probably the worst trick one can use to deal with partial order.

by gritzko 13y ago

josephg 13y ago
Care to justify that assertion? I think OT is a fantastic way to deal with partial order. OT can be used to guarantee eventual consistency while preserving intent. And unlike transactions, it lets you edit your local model syncronously in the client without waiting for a server round-trip. When you have a stack that can do it, its a really great system.
- gritzko 13y ago
  First of all, I know what I am talking about; I published on the subject, I also created a working system (CRDT-based). Second, in my understanding, transactions don't deal with partial order; they do linearization. That indeed requires a round-trip. Third, I also sketched some OT-based solutions, so I saw both sides of the coin. According to my experience, OT is terribly complex and fragile. Basic principles are simple, but various concurrency issues make it a nightmare further down the road. Operations are rewritten in several places, all those rewrites are interdependent, partial failures create really tricky situations, etc. Fourth, Google has a working OT stack, but they also have a working Paxos. They simply have too many brainy folks and too much of equipment/money, probably. Fifth, all the problems OT solves by entangled op rewrite trickery can be trivially solved by brute force (not that much of force actually, see CRDT). Sixth, the very notion of "intent" in OT was a really really big misnomer. "Intent" is OK for a legal term, but it is terrible for CS, as it has no intuitive formal meaning (as opposed to "convergence", for example). Seventh, OT has a strong "magic factor". It is too smart kind of, so it strikes a spark of excitement in some folks. That is often a bad thing (see eg "digital fountains").
  - gritzko 13y ago
    P.S. "implementing OT sucks" -- Joseph Gentle

Repeatedly rewriting operations in-flight is probably the worst trick one can use to deal with partial order.

by gritzko 13y ago

Repeatedly rewriting operations in-flight is probably the worst trick one can use to deal with partial order.

Care to justify that assertion? I think OT is a fantastic way to deal with partial order. OT can be used to guarantee eventual consistency while preserving intent. And unlike transactions, it lets you edit your local model syncronously in the client without waiting for a server round-trip. When you have a stack that can do it, its a really great system.

gritzko 13y ago
First of all, I know what I am talking about; I published on the subject, I also created a working system (CRDT-based). Second, in my understanding, transactions don't deal with partial order; they do linearization. That indeed requires a round-trip. Third, I also sketched some OT-based solutions, so I saw both sides of the coin. According to my experience, OT is terribly complex and fragile. Basic principles are simple, but various concurrency issues make it a nightmare further down the road. Operations are rewritten in several places, all those rewrites are interdependent, partial failures create really tricky situations, etc. Fourth, Google has a working OT stack, but they also have a working Paxos. They simply have too many brainy folks and too much of equipment/money, probably. Fifth, all the problems OT solves by entangled op rewrite trickery can be trivially solved by brute force (not that much of force actually, see CRDT). Sixth, the very notion of "intent" in OT was a really really big misnomer. "Intent" is OK for a legal term, but it is terrible for CS, as it has no intuitive formal meaning (as opposed to "convergence", for example). Seventh, OT has a strong "magic factor". It is too smart kind of, so it strikes a spark of excitement in some folks. That is often a bad thing (see eg "digital fountains").
- gritzko 13y ago
  P.S. "implementing OT sucks" -- Joseph Gentle