Yes, as far as I know its impossible (Or at least impractical - you'd need to have garbage collection). But thats ok - implementing a rich text type is *easier* than implementing a JSON type.
I recently paired with the author of quilljs and stypi to port his rich text OT type for quill into sharejs. It works great. My big learning from a lot of this stuff is that semantics for different kinds of data are different, and you need to be able to support that in your system. -J On Tue, Jul 8, 2014 at 7:14 PM, 田传武 <i...@goodow.com> wrote: > 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 >>
