Yeah exactly. The google wave OT code uses special operations that can understand the XML structure. It doesn't just edit the plaintext. Formatting annotations are stored in a special way - operations can say something like "At position 10 add bold. At position 20 stop adding bold".
-J On Wed, Jun 12, 2013 at 1:56 PM, Bruno Gonzalez (aka stenyak) <sten...@gmail.com> wrote: > 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
