On 30/04/13 21:12, Marcelo Galvão Póvoa wrote:
> there are indeed several possible approaches. I will try to briefly
> describe mine and you can comment about its (in)feasibility.
As you say, your case was far easier, and it seems to correspond to the
simple scenario of editing text in a text-only paragraph.
Criticalities already discussed on the list: keep position as an offset,
it's basically what LyX does, but in a structured form. A Cursor is a
stack of CursorSlice, where each slice is basically a triplet
<pos, pit, idx>
where pos indicates the character position in the text, pit (ParagraphIT)
indicates the paragraph number in the multi-paragraph text, idx indicates
what cell of a multi-cell table we're in. Then, we have a stack of these,
because in a given pos we might have, instead of a normal character, a
kind of placeholder indicating there's an inset there. So, we go to the
inset, which in turn is another kind-of LyX text, with potentially its
own multi-paragraph text etc....
So, another user edits creating further pars or deleting pars, and we
need to pay attention to cursor positions after them.
> edits are only of types "insert text" or "delete text", represented as
> (global-offset, type, data),
pls, have a look at LyXAction.cpp to get a feeling of the possible edit
actions that users might be willing to do (I'm not pretending that all
of them should work in the interactive editing mode -- perhaps we just
allow a subset of them to be used in that mode; ideally, we'd like all
of them to keep working).
Now, the hack I did, was rude: keep the serialized LFUN (in form of
text), send to the other side, reconstruct the LFUN, dispatch it
locally. INCLUDING CURSOR MOVEMENTS, which are relative (go up, go
right one char, etc...). That was causing easy de-synch between the
two sides, about what position the cursor is, when dispatching an
editing LFUN. So, there should be a way to exchange and keep in synch
the cursor position independently of the multiple edits being merged
within the doc.
That's why sb. proposed to use par hashes to identify the par, or global
unique identifiers, etc.... We all know how a version control system
does that, by the +/- 3 lines around the edit..., and we know the
limitation of such an approach. What can we do in such case ?
> A "document revision" is a document state (identified by an integer)
Good. Doc revision may be helpful. As highlighted by Nico, if we know
the revision against which an editing LFUN dispatch was meant, we might
know what position to affect, but still in case of replay of other users'
concurrent editing LFUNs, the key point is how to translate/transform
the subsequent actions..
> The main advantages of this approach are simplicity and avoid dealing
> with locking, conflicts, etc.
would it be applicable to the nested/structured LyX text, as described
above ? or, how to extend it properly in such case ?
> As someone mentioned, when two users are
> editing too close to each other, there is no correct result for this.
As I see it, if others' cursors are close to mine, then when I start
typing, LyX should delay a bit the action, so as to ensure I "lock"
some part of text where others wouldn't be able to edit. Then, perhaps
after a time-out I don't edit any more that part, it's released. The
locked part might be highlighted some-way in the GUI, both for the
user with the lock (~~green leftbar or similar), and for the one(s)
without (~~red leftbar or similar).
Just thinking aloud, it might be extremely handy to have a chat pane
for being able to discuss about the doc while editing, w/out typing
the stuff straight into the doc.... :-)!
In the end, I keep seeing lots of relations within the two projects,
with possibly the chat being a part of the overall collaboration
features.
> As a drawback, clients need to keep track of the latest document
> revision: if one misses a revision (the user leaves but the document
> keeps being edited by others), he should ask someone for the whole
> document.
knowing what was changed in each revision, it should be possible to
re-send only the affected/changed parts...
T.
