What sort of operations do you have on the JSON OT type? That will help
me comment.
On 6/12/13 10:55 PM, "Joseph Gentle" <jose...@gmail.com> wrote:
>Really?
>
>My method for ShareJS was to simply have a JSON OT type and a
>plaintext OT type. I'd like to add a rich text OT type as well. Then
>people can just pick which one based on what kind of data they have.
>
>For Wave I'd like to be able to do something similar - JSON is
>obviously useful for storing application data. It'd be nice to have
>some sort of hybrid for wavelets where we can put multiple different
>kinds of data inside a wavelet. One option is to use a JSON OT type as
>the root of all wavelets and support subdocuments at arbitrary paths
>(so the object could be:
>{projectName:"ruby on rails", files:[{name:'foo/bar.rb', ...}],
>documentation:{_type:richtext, _data:"<Rich text data>"}}
>
>Or wavelets could simply each have a type (defaulting to the current
>wavey XML type).
>
>-J
>
>
>On Wed, Jun 12, 2013 at 2:41 PM, Michael MacFadden
><michael.macfad...@gmail.com> wrote:
>> You have stumbled upon one of the weaknesses of wave OT. Best practices
>> would say to NOT bind your OT directly to the data type, because then
>>you
>> don't have an extendable model. For example if you have all of your
>> operations figured out and validated, and then you need to change your
>> data model, you have to go back and mess with your transformation
>> functions. Not good. Or you have to try to bend new data models in to
>> the existing one, also not good.
>>
>> Best practice is to create a generic OT model and operate on that.
>>There
>> is debate as to what the model should be, but most agree on the concept.
>>
>> For example in wave they tried to create a map like collection that OT
>> could operate on. Essentially though that had to implement the map as if
>> its underlying model was a bunch of XMLish type tags. This we very
>> convoluted.
>>
>> ~Michael
>>
>> On 6/12/13 10:26 PM, "Joseph Gentle" <jose...@gmail.com> wrote:
>>
>>>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
>>
>>
