No that is not it at all. You misunderstand my comments. I am not
actually suggesting you store ANYTHING in a JSON string. The point is
that the wave model store as Objects. There is an actual object some where
in memory that defines the text, lines, annotations etc.
When you do operations in ShareJS, are you really thinking about JSON
Objects a strings in the JSON format, or are you thinking about
manipulating an object. I think it is the latter. Looking at your API,
you have methods at add things to arrays and set properties. So your
operational language is aligned to manipulating object models.
As such you could manipulate any arbitrary object structure, a JSON
object, a wave document model, etc.
~Michael
On 6/13/13 7:54 PM, "Joseph Gentle" <jose...@gmail.com> wrote:
>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.
>
>-J
>
>
>On Thu, Jun 13, 2013 at 1:19 AM, Michael MacFadden
><michael.macfad...@gmail.com> 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" <jose...@gmail.com> 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.
>>>
>>>-J
>>>
>>>
>>>On Wed, Jun 12, 2013 at 4:06 PM, Michael MacFadden
>>><michael.macfad...@gmail.com> wrote:
>>>> 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
>>>>
>>>> Potentially.
>>>>
>>>>
>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
