|
|
|
|
|
|
by Jyaif
462 days ago
|
|
|
> All this recent hype about sync engines and local first applications completely disregards conflict resolution The main concern of sync engines is precisely the conflict resolution! Everything else is simple in comparison. The good news is that under some circumstances it is possible to solve conflicts without user intervention. The simplest example is a counter that can only be incremented.
More advanced data structures automatically solving conflicts exists, for example solving conflicts for strings exists, and those are good enough for a text editor. I agree that there will be conflicts that are resolved in a way that yields non-sensical text, for example if there are 2 edits of the sentence "One cat": One cat => Two cats One cat => One dog The resulting merge may be something like "Two cats dog".
Something else (the user, an LLM...) will then have to fix it. But that's totally OK, because in practice this will happen extremely rarely, only when the user would have been offline for a long time. That user will be happy to have been able to work offline, largely compensating the fact that they have to proof read the text again. |
|
|
It can be acceptable for some usecases, but not for others where you're still concerned about stuff that happens "extremely rately" and is not under your direct control.
> Something else (the user, an LLM...) will then have to fix it.
This assumes that user/llm knows the conflict was automatically solved and might need to be fixed, so the conflict is still there! You just made the manual part delayed and non-mandatory, but if you want correctness it will still have to be there.