incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael MacFadden <>
Subject Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]
Date Wed, 12 Jun 2013 23:06:19 GMT
Actually I just went and took a look at your operations.  The JSON OT type
is probably the closest to what I would suggest we use.  JSON Objects are
not just for javascript.  They define arbitrary objects structures.  We
don't need a specific wave XML type, we could use the JSNO operations to
modify the conversation model


On 6/12/13 10:55 PM, "Joseph Gentle" <> wrote:

>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).
>On Wed, Jun 12, 2013 at 2:41 PM, Michael MacFadden
><> 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
>> 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.
>> 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" <> 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".
>>>On Wed, Jun 12, 2013 at 1:56 PM, Bruno Gonzalez (aka stenyak)
>>><> wrote:
>>>> I suspected something like that. I assume it also correctly handles
>>>> variable-length UTF8 characters, so it's not necessarily 1-byte
>>>> This starts to make sense. OT can only compute conflict-free merges
>>>> the "character" primitive (because that's how Wave was originally
>>>> designed). As an unfortunate consequence, you can then only OT-operate
>>>> plain text. Otherwise you could get conflict-free xml text that
>>>> li<>ke>this>, and that of course isn't legal xml.
>>>> But we still want rich text in Google Wave, therefore all the
>>>> stuff is stored some place else, specifically in the blip annotations.
>>>> 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
>>>> primitive, but rather an "xml tag" primitive, a json item, a "pixel",
>>>> anything else, right?
>>>> (sorry for only contributing with questions... :-)
>>>> On Wed, Jun 12, 2013 at 10:27 PM, Joseph Gentle <>
>>>>> On Wed, Jun 12, 2013 at 12:13 PM, Bruno Gonzalez (aka stenyak)
>>>>> <> wrote:
>>>>> > My assumption was that conflicts were simply mathematically
>>>>> 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
>>>>> > conflicts "eliminated" by choosing an arbitrary merging strategy
>>>>> > conflicts *do* happen (e.g. "choose the last timestamped patch and
>>>>> > information on the way, we don't care"), or can they be prevented
>>>>> ever
>>>>> > happening in the first place?
>>>>> They're inevitable in patch based systems because patches usually
>>>>> 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
>>>>> >
>>>> --
>>>> Saludos,
>>>>      Bruno González
>>>> _______________________________________________
>>>> Jabber: stenyak AT

View raw message