About rich text support using JSON, i think Joseph Gentle may know the
answer, see:
https://github.com/share/ShareJS/issues/1
@Joseph can you comment on this?
On Tue, Jul 8, 2014 at 11:30 PM, Kythyria <kythy...@gmail.com> wrote:
> On 07/08/14 12:42, Thomas Wrobel wrote:
>
>> Thats really cool work.
>> Seems to work slickly, and theres mobile library code already.
>>
>> Someone needs to make a ven diagram of various communication techs and
>> their features. As I understand it this has the functionality of the wave
>> protocol except for the federation right?
>>
>> Just a random thought, but seeing as theres occasionally calls for the
>> Wave
>> code base to be scrapped and recreated (faster/better/stronger/neater...)
>> would it make sense to build a new WFP out of this, rather then trying to
>> wrangle the existing code into shape? Or is that a crazy idea?
>>
>
> It looks JSON-shaped, which Wave's data model may or may not be compatible
> with. There'd certainly need to be a lot of wrangling to get them to line
> up!
>
> I haven't been able to figure out a way to represent rich text in a system
> such as OP's that can only do JSON. Storing annotations separately means
> the system has to know how to change them in response to operations that
> affect the indexes used, while interleaving that information with the text
> appears to require a split-string-in-list operation.
>
> For the first option, if we have:
> { text: "foo barrow baz", annotations: [] }
>
> and Alice wants to make "row" bold, she might insert into the annotation
> list:
> list-insert(annotations[0], {range: [7,10], key: "font-weight", value:
> "bold"})
>
> at the same time as Bob sends another change:
> string-insert(text[7], "ton")
>
> Then a system not aware of the relationship between text and annotations
> will end up with:
> { text: "foo bartonrow baz", annotations: {range: [7,10], key:
> "font-weight", value: "bold"}}
>
> (ie, "row" isn't emboldened)
>
> When the expected result would presumably be:
> { text: "foo bartonrow baz", annotations: {range: [7,13], key:
> "font-weight", value: "bold"}}
>
> to account for the extra three characters.
>
> For the second option, split-string-in-list, that initial state might be:
> { text: ["foo barrow", " baz"]}
>
> Alice's change, without split-string-in-list, would be:
> list-delete(text[0])
> list-insert(text[0], "foo ")
> list-insert(text[1], { key: "font-weight", value: "bold" })
> list-insert(text[2], "barrow")
> list-insert(text[3], { key: "font-weight", value: nil})
>
> And Bob's would be:
> string-insert(text[0][7], "ton")
>
> An unaware engine might either drop Bob's change on the floor, or put it
> in the wrong place:
> { text: [
> "foo ton",
> { key: "font-weight", value: "bold" },
> "barrow",
> { key: "font-weight", value: nil}
> ]}
>
> That said, there *are* designs for lists/strings that give identifiers
> stable under this sort of thing, but the one I've seen[1] has its own set
> of issues, like not being able to execute housekeeping operations while any
> participants are disconnected!
>
> [1] http://arxiv.org/abs/0710.1784
>
