On Mon, Apr 29, 2013 at 6:03 PM, Tommaso Cucinotta <tomm...@lyx.org> wrote:
> On 29/04/13 23:32, Nico Williams wrote:
>>> However, when considering that other users might be editing stuff
>>> above/before our
>>> cursor position, then it means this way of referencing positions within the
>>> text
>>> should be changed/reworked to a pointer-based one.
>>
>> But what alternative addressing schemes could there be?
>
> well, when I wrote pointer, I actually meant C/C++ pointer :-). It's fixed,
> it doesn't change, it simply refs the paragraph, regardless of what other
> paragraphs precede it, or whether it is moved around (ParagraphList is a
> list, isn't it ?)
Well... If a paragraph is deleted then the pointer might get assigned
in a subsequent allocation and... you end up with an aliasing problem.
I strongly recommend instead that you have a "paragraph ID" (call it
pointer if you like), saved in .lyx (this is important), and
consisting of two things:
- a local LyX/host/whatever instance ID (can be re-generated every
time LyX starts)
- a paragraph ID that is assigned (and saved in the .lyx!) when the
paragraph is created (if an old .lyx doesn't have this... then assign
one at open / conversion time).
> Now, the problem comes when deleting a paragraph: we need to check that no
> other cursors are on it, otherwise either forbid the operation or move the
> other cursors at the end of the removed part.
You can't do that. Assume chat servers/peers come and go. You don't
want to wait potentially forever, and you don't want to implement a
distributed locking protocol (for the same reason). Nor do you want
to worry about split-brains (netsplits).
> Further issue is characters, as there's no list of characters in LyX, AFAICR,
> but it's a contiguous array. So, for chars there seems to be no other way
> than keeping a pos index..., or reworking that as a CharacterList.{h,cpp},
> which I'm quite sure somebody wouldn't like.
Version everything and assign version numbers; keep history.
Alternatively use hash-of-paragraph-contents as version numbers; keep
history.
> Given also issues raised in that a newcomer should not be messing around the
> core of LyX and refactor the cursor, because of the risk of entering a
> stability nightmare, it may be valuable to consider to keep the cursor as
> it is, and instead add the necessary logic to modify affected cursors of
> other concurrent editors consistently with the action.
>
> For example:
> -) when inserting a new character (LFUN_SELF_INSERT):
> for each cursor in same par in positions beyond this, do a pos++
> -) when inserting a new par (on Enter):
> for each cursor in later pars, do a pit++
> -) others for cut'n'paste, etc...
> -) I know, cases will grow fast...
See above. You can't really synchronize this way.
Instead you want to have each LyX instance see something like a stream
of events, some locally-generated, some not. You can get out of sync
with such a scheme, but i think you can arrange (by keeping enough
history) to resolve conflicts deterministically to end up with the
same content. However, if two or more LyX instances continue to edit
for long enough through a netsplit then you may have to have the users
merge conflicting paragraphs.
>> I'm thinking
>> of a hash-based scheme, something like {{hash of paragraph contents},
>> offset into paragraph.
>
> while extremely git-ish :-), it would have the problem of identical paragraphs
> that are very possible in documents (e.g., right after a copy'n'paste).
Assigning a globally-unique paragraph ID on paragraph create is safer.
But LyX could easily allow a paragraph to have copies in multiple
places in the same doc either way, but it's all much easier with
globally-unique paragraph IDs.
Nico
--
