[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: IRC log - ODF Collab SC call - 2017-04-19
[16:41] Svante Schubert: Aside of Eastern holiday, I did a relase for ODF library called http://incubator.apache.org/projects/odftoolkit.html
[16:45] Svante Schubert: Patrick mentioned Ropes and we compared Ropes (data structure) and Strings, see https://en.wikipedia.org/wiki/Rope_(data_structure)#Comparison_with_monolithic_arrays
[16:46] Svante Schubert: Patrick: Very large strings and persistence, undo/redo ropes are better..
[16:46] Patrick: one question is how to represent changes in the XML -
[16:47] Patrick: If treat XML as a string, then if an implementation uses rope data structures - collaboration and unlimited redo become possible even with milestones
[16:48] Patrick: for example, if a change starts in the middle of an element and continues to the middle of the next element, the rope extends the change to the containing elements and so has the markers (milestones) for display in the UI
[16:49] Patrick: to capture changes, all I really need in markup are the milestones with MS attribute for who, ... , and matching end milestones.
[16:51] Patrick: separate the concern for marking changes and the content of those changes, addition or deletions, from the actual collaboration/change tracking of the implementation, then the format issues become simplier.
[16:52] Svante Schubert: We should be careful not to forget, that ODF XML is not a run-time relevant/existent format, but only being used as serialization format, oppose to HTML
[16:52] Svante Schubert: When we talk about string vs. ropes we are talking about the run-time model
[16:54] Patrick: xml is serialization versus string/ropes which are run-time
[16:54] Patrick: how to serialize changes in the XML, however they are processed in the run-time
[16:55] Svante Schubert: XML are the atoms of the documents. Documents are being exchanged across applications. Currently ONLY documents can be exchanged across application borders, which is not sufficient to merge changes or to 'ask' what has changed.
[16:59] Patrick: <text:p>hello</text:p>
[17:00] Patrick: <text:p>hello<change> world</change></text:p>
[17:00] Svante Schubert: ^^yes, that is the old way of doing change-tracking
[17:01] Svante Schubert: not allowing overlapping change-tracking and hard to impossible to remove a change in the list of changes
[17:01] Svante Schubert: The document is equivalent to the edit script (the recipe to create the document) --> add paragraph @/1; add text @/1/1
[17:02] Svante Schubert: --> add paragraph @/1; add text "hello" @/1/1
[17:02] Patrick: <text:p>hello<change author="svante" time="sometime" id="aoo1"> world</change><text:p id="a001"/>
[17:02] Svante Schubert: the new change that can be dispatched to other applications oppose to sending the complete document, could be: add text " world" /1/6
[17:03] Patrick: <text:p>hello<change author="svante" time="sometime" id="aoo1"/> world</change><text:p id="a001"/>
[17:03] Patrick: <text:p>hello<change author="svante" time="sometime" id="aoo1"> world</change id="a001/></text:p>
[17:04] Patrick: add paragraph @/1; add text "hello" @/1/1
[17:05] Svante Schubert: change tracking would nowadays hold a list of undo changes aside the content.
[17:06] Patrick: author + time + base + change
[17:09] Patrick: why can't a change specify a series of changes required by a change?
[17:13] Svante Schubert: We need to specify:
[17:13] Svante Schubert: 1) What are the allowed/possible changes
[17:14] Svante Schubert: 2) How do we merge changes
[17:15] Svante Schubert: ^^ merge is not always automatic, there might be conflicts that user have to decide on
[17:17] Patrick: exchanging of documents doesn't support collaboration and doesn't scale
[17:18] Patrick: need operations (auditable) on sub-parts of documents across distributed authors
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]