I suspected something like that. I assume it also correctly handles variable-length UTF8 characters, so it's not necessarily 1-byte patches?
This starts to make sense. OT can only compute conflict-free merges using the "character" primitive (because that's how Wave was originally designed). As an unfortunate consequence, you can then only OT-operate on plain text. Otherwise you could get conflict-free xml text that <loo<ks li<>ke>this>, and that of course isn't legal xml. But we still want rich text in Google Wave, therefore all the formatting stuff is stored some place else, specifically in the blip annotations. The modifications to annotations are (sometimes) simply derived from the transformations that the plain text suffers after merges? I suppose there could be other OT algorithms that don't use a "character" primitive, but rather an "xml tag" primitive, a json item, a "pixel", or anything else, right? (sorry for only contributing with questions... :-) On Wed, Jun 12, 2013 at 10:27 PM, Joseph Gentle <jose...@gmail.com> wrote: > On Wed, Jun 12, 2013 at 12:13 PM, Bruno Gonzalez (aka stenyak) > <sten...@gmail.com> wrote: > > My assumption was that conflicts were simply mathematically inevitable > in a > > DVCSs, that's why your mention about lack of conflict markers sparked my > > interest... you mention conflicts like they can be optional? If so, are > > conflicts "eliminated" by choosing an arbitrary merging strategy when > > conflicts *do* happen (e.g. "choose the last timestamped patch and lose > > information on the way, we don't care"), or can they be prevented from > ever > > happening in the first place? > > They're inevitable in patch based systems because patches usually have > a line level granularity. OT usually uses individual character > positions. In OT, if two operations both delete the same character, > the character gets deleted once. If two clients insert a character at > the same position, one of the characters will be first in the > resultant document and one will be second. Conflict markers just > aren't necessary. > > -J > > > -- > > Saludos, > > Bruno González > > > > _______________________________________________ > > Jabber: stenyak AT gmail.com > > http://www.stenyak.com > -- Saludos, Bruno González _______________________________________________ Jabber: stenyak AT gmail.com http://www.stenyak.com
