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

[Friedrich W. H. Kossebau]

Hi Philip,

Am Mittwoch, 19. Juni 2013, 00:34:24 schrieben Sie:
> Hi Friedrich,
> 
> The proposal looks good.
> 
> Once concern that I did have is that there is potentially not enough
> flexibility. I'm thinking about table insertion specifically where the
> desired location of the cursor when inserting a table is actually within
> the first paragraph in the first cell of the table.
> 
> There are two potential ways to address this that immediately come to mind:
> 
> 1. Make the setOwnCursor a little more flexible by allowing specific
> placement of the cursor at the completion of an operation. As long as the
> Ops respect the fact that setOwnCursor is RELATIVE to the input position,
> this should cause no hassles for OT adaption on conflict etc. (e.g., an Op
> should not set the cursor beyond the bounds of it's known neighbour hood,
> so for the table, it will insert the cursor within the first paragraph
> itself).

While for simplicity I would prefer to have a single defined position where 
the related cursor ends up after insertion (of a table), I do not see any 
technical reason against having an option where to place it exactly. So no 
problem to add support for that.

> 2. Keep cursor positioning a separate concern from the operation. The
> expectation here would be that an operation is NOT responsible for managing
> cursor position, instead, the upper controller (SessionController) is
> responsible for this. The key advantage of this is that it keeps the notion
> of cursor positioning entirely in the domain of the SessionController,
> rather than requiring each OP to find and manage it's own cursor (or even
> other cursors). I suspect this would help simplify the Ops slightly as they
> would focus more on doing things to the DOM, and would no longer need to
> worry about whether insertion is before or after the cursor etc.
> 
> In the example of a table insertion, approach 2 would generate:
> OpInsertTable
> OpMoveCursor (move to first paragraph of new table)

While I would prefer approach 2 as well, due to the less complexity in the 
semantics of the ops and the work they have to do, it poses me in front of a 
problem I yet have to solve, i.e. to do proper transformations of the 
movecursor ops which are intended to put the cursor after the result of the 
preceding document manipulation. Because I would need to know how the related 
manipulating op is transformed to also properly adapt the moveCursor op. So 
this dependency just adds other complexity elsewhere, and here I do not even 
have a good idea yet.

Given the example from my initial email, where both users insert at the first 
position of an empty document:

At A:
<insertText pos="0" text="a" memberId="A"/><moveCursor pos="1" memberId="A"/>
At B:
<insertText pos="0" text="b" memberId="B"/><moveCursor pos="1" memberId="B"/>

A first sends to server:
Server:
<insertText pos="0" text="a" memberId="A"/><moveCursor pos="1" memberId="A"/>

Now B tries to sync and has to transform the ops from A and its unsynced own 
against each other in such a way that the result looks like this when A later 
fetches the (transformed) ops from B (via the server):
A:
<insertText pos="0" text="a" memberId="A"/><moveCursor pos="1" memberId="A"/> 
<insertText pos="1" text="b" memberId="B"/><moveCursor pos="2" memberId="B"/>
B:
<insertText pos="0" text="b" memberId="B"/><moveCursor pos="1" memberId="B"/>, 
<insertText pos="0" text="a" memberId="A"/><moveCursor pos="1" memberId="A"/>

When transforming a moveCursor op against a insert/remove/split (so position 
number) changing op, the current transformation logic only changes the 
position of a moveCursor op by the number of inserted/removed positions before 
the old position of the moveCursor op. But here it would also depend on the 
transformation of the preceding document manipulation op, e.g. in the given 
example the moveCursor op for cursor of member A on client B should stay at 
position 1 and not be adapted by +1 when transformed against the insertText op 
of member b at pos 0, because the related insertText op of A was also not 
adapted by +1, due to "winning" the tiebreaking in whose insertion should end 
up at position 0.

Will think some more about it, just giving a first reply.

Cheers
Friedrich
-- 
Friedrich W. H. Kossebau // KO GmbH
http://kogmbh.com/legal/