Am Samstag, 22. Juni 2013, 00:10:40 schrieb Jos van den Oever:
On 06/17/13 12:39, Friedrich W. H. Kossebau wrote:
Hi WebODFler,
I would like to add a new property to the specs of all insert/remove/split ops: setOwnCursor (or some better name). This property will tell if the cursor of the member which sends the operation should be put after the place/result of the op. Currently this is only done iff the cursor is at the position of the op. But with real OT, where local operations are instantly applied and only then sent to other clients who might have to transform them on conflicts, the transformed operations and positions of cursors can be out-of-sync, breaking the current assumption with UI editing that cursors will always automatically placed behind the places of modification.
Ok, I wrote a long email with different scenarios and orders of operations. I have discarded this mail because I came to the conclusion that the problem is not with the occurrence of an out-of-sync with an assumption of how cursors should move upon inserting or deleting text.
Here is the original example. I have added a | to show the insertion point. text:p|<cursor memberid="A"/><cursor memberid="B"/>
Why do you put the insertion point before the cursors? How would you argument for this ordering? Why this way do you bound the cursors more to the following and less to the preceding content?
The two participants each insert a character locally: text:p|a|<cursor memberid="A"/><cursor memberid="B"/> text:p|b|<cursor memberid="A"/><cursor memberid="B"/> They do this by sending: <insertText pos="0" text="a" memberId="A"/> <insertText pos="0" text="b" memberId="B"/>
This is sent to the server and either 'a' can get there first or 'b' can get there first: text:p|a|b|<cursor memberid="A"/><cursor memberid="B"/> text:p|b|a|<cursor memberid="A"/><cursor memberid="B"/>
There is no need to send any command to move a cursor.
The two results I show above is not in conformance with "the current assumption with UI editing that cursors will always automatically placed behind the places of modification" and that is fine. The cursor is not actively placed, it just goes with the flow.
Sure the cursor for A might not be directly behind the character 'a' or the cursor for B might not be directly behind the character 'b' when these participants start typing on the same location. I do not think this is a problem.
It is a problem in this case: two clients are connected to the server, thus syncing in real-time, and both users start typing at the same time with their cursors at the same position (like an empty document). Their input will be be interleaved (because the positions of their cursors will not be separated, unless one uses cursor move command), which is surely not what people like and expect. At least this is the reasoning why we (as in: those who talked about that last time) decided to only move the cursor of the member doing the insertion behind the inserted object and leave any other cursors at the point of the insertion. And this is also the behaviour like it is implemented currently.
The original mail claimed that the result of A typing an 'a' would be text:p<cursor memberid="B"/>a<cursor memberid="A"/> but this is not true, the result should be: text:pa<cursor memberid="A"/><cursor memberid="B"/> because the text should be inserted before the insertion point.
Should it? What would be the reasoning? What defines "truth" here? :) For reference, Etherpad, Gobby (infinote protocol) & Google Docs all only move the cursor of the editing person behind the insertion and leave any other cursors at the insertion point in place.
I hope this clarifies things.
Clarifies at least we need to document our (previous/future) decisions and for that add a design document to webodf :) IMHO we should rather stick with the current implementation, where only the cursor of the editing member is placed behind inserted objects (or alternatively also inside, like the first cell of an inserted table). Not only for consistency with the systems mentioned above, but also for this reasoning: The flow in the structure which is edited here (text document) is from beginning towards end, and people usually change this structure by appending more content to other content, rather than prepending. Like I type all the letters to this email by appending, yes, really do :) So if one places a cursor somewhere the cursor more often is put _behind_ content than put _before_ content. Thus on insertion at that point the non-involved cursors should stick to the previous content. And it would also unbreak the interleaved input issue, but that is related to this argueing. Downside is some more complicated code and operations, sure. But well... Other opinions on this? Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/