incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Gentle <>
Subject Re: Future of Apache wave [Was: Re: Advantages of P2P messaging?]
Date Thu, 13 Jun 2013 18:54:40 GMT
So you're imagining storing rich text like this?

{doc: 'hi there!', annotations: [{from:0, to:2, bold:true}]} or something?

Every change to the document is going to need to manually update every
single annotation which has start / end points after the edit. But it
wouldn't work - if you insert some text and I edit an annotation later
in the document, my annotation will float forwards / backwards when I
get your op because I don't know how I should change it.

This idea comes up about every 6 months on the sharejs mailing list.
Several solutions have been proposed, but none of them work correctly.
I think we just need a separate set of transform / apply / ...
functions for rich text.


On Thu, Jun 13, 2013 at 1:19 AM, Michael MacFadden
<> wrote:
> Joseph,
> I disagree.  The annotations themselves are just another data structure.
> You add them, remove them and modify them like anything else.  You can
> manage annotations as another structure within the blip model.  There is
> no reason why you can interface them though a JSON Style operations
> structure.
> ~Michael
> On 6/13/13 12:11 AM, "Joseph Gentle" <> wrote:
>>The conversation *model* yes, but not the rich text documents
>>themselves. You can't really make text annotations work properly on
>>top of JSON operations. We should keep something like the current
>>system for actual blips.
>>On Wed, Jun 12, 2013 at 4:06 PM, Michael MacFadden
>><> wrote:
>>> Actually I just went and took a look at your operations.  The JSON OT
>>> is probably the closest to what I would suggest we use.  JSON Objects
>>> 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
>>> Potentially.
>>> 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
>>>>> 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
>>>>> 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
>>>>> 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
>>>>> 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
>>>>>>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
>>>>>>> the "character" primitive (because that's how Wave was originally
>>>>>>> designed). As an unfortunate consequence, you can then only
>>>>>>> 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
>>>>>>> modifications to annotations are (sometimes) simply derived from
>>>>>>> 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
>>>>>>> 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
>>>>>>>>sparked my
>>>>>>>> > interest... you mention conflicts like they can be optional?
>>>>>>>> > conflicts "eliminated" by choosing an arbitrary merging
>>>>>>>> > conflicts *do* happen (e.g. "choose the last timestamped
>>>>>>>> > 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
>>>>>>>> a line level granularity. OT usually uses individual character
>>>>>>>> positions. In OT, if two operations both delete the same
>>>>>>>> the character gets deleted once. If two clients insert a
>>>>>>>> the same position, one of the characters will be first in
>>>>>>>> resultant document and one will be second. Conflict markers
>>>>>>>> aren't necessary.
>>>>>>>> -J
>>>>>>>> > --
>>>>>>>> > Saludos,
>>>>>>>> >      Bruno González
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > Jabber: stenyak AT
>>>>>>>> >
>>>>>>> --
>>>>>>> Saludos,
>>>>>>>      Bruno González
>>>>>>> _______________________________________________
>>>>>>> Jabber: stenyak AT

View raw message