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

[Friedrich W. H. Kossebau]

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"/></text:p>

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>
>    <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.

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"/></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.

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/