[WebODF] Adding spec property "setOwnCursor" for Insert/Remove/Split ops

[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"/></text:p>
The two participants each insert a character locally:
   <text:p>|a|<cursor memberid="A"/><cursor memberid="B"/></text:p>
   <text:p>|b|<cursor memberid="A"/><cursor memberid="B"/></text:p>
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>
   <text:p>|b|a|<cursor memberid="A"/><cursor memberid="B"/></text:p>

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.

The original mail claimed that the result of A typing an 'a' would be
  <text:p><cursor memberid="B"/>a<cursor memberid="A"/></text:p>
but this is not true, the result should be:
  <text:p>a<cursor memberid="A"/><cursor memberid="B"/></text:p>
because the text should be inserted before the insertion point.

I hope this clarifies things.

Cheers,
Jos