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/