On 30/04/13 23:10, Marcelo Galvão Póvoa wrote:
> I think the best approach is not treating the LFUN as edits themselves
> but their effect on the document text instead.
Dispatching LFUNs has the advantage of not subverting the way LyX edits
docs, internally, and also re-use them. For example, you want to insert
a char, and that's exactly what's conveyed in LFUN_INSERT_SELF. Similarly
for delete actions. However, we simply need to fix and additionally send
more info about the position relative to which each action should be done
(i.e., doc or par ID, revision, and position within).
> Many of them doesn't
> touch the text, so it's useless to send to the other party.
When working the Advanced Find & Replace machinery, we had to distinguish
among LFUNs that would dispatch into the F&R workarea, from ones that would
dispatch into the main document being edited workarea. I think that thing
is reusable for specifying which LFUNs should dispatch anyway locally, vs
which ones would go to the other side. It should be a further flag to be
added to the LFUN description in LyXAction.cpp.
> As for the
> others, the idea is to serialize each one into a string that represent
> their textual output. For example, it could be translated to LyX file
> syntax itself, couldn't it? The other party would deserialize this
> content filling the appropriate LyX data structures. I hope that the
> LyX functions for Save and Load could be reused for that matter.
You could, but I'm not sure about what advantage you get. LyX keeps in
memory a structured graph of C++ objects, not their serialized version.
If you send a serialized paragraph, then you have to de-serialize it
replacing the corresponding C++ object(s) on the other side, but a
paragraph may be veeeeery long. Instead, we might want to send just
the editing action, that normally should be smaller to be sent.
Also, when deleting a paragraph what do you send ? In the end, we need
anyway to send positions referring to affected parts of the document,
in a way that is as safe as possible considering others possibly being
editing other parts.
> I claim that the sorting algorithm I loosely described works for that
> purpose (maintaining consistency), assuming that all users generate
> edits based on the same revision.
But that's the critical point: users won't be able to generate edit msgs
based on the same revision, unless you synch all of them on a master doc.
That may be easy, as discussed with Nico, but it risks of resulting in a
bad experience (wait for a round-trip time before seeing any char on
screen ? hmmm....)
Please, try to describe it in detail in your proposal, considering also
the issues discussed in this thread.
>> 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).
>>
>
> I agree with Nico here. A lock is not necessary: when someone starts
> editing a section, the others will see that and shouldn't interfere.
I'm absolutely all for users who will synch by themselves / other means,
in such cases. But, should a user try to edit over another user's cursor,
what'd you do ? I'm just saying LyX will automatically remind them that
they shouldn't be messing up with what the other guy is doing, in that
specific region of text. Otherwise they risk their edits to go lost.
Now, don't assume locking is bad. It's not a lock in the traditional
sense, just a highlighting of the risk.
Now, I can see two variations: I'm not allowed to edit such locked region,
which is what simplifies implementation. Or, when I try to edit, I get a
warning by LyX: look, I'm not sure I can make sense of concurrent edits.
Would you like to proceed ? If the user confirms, then apply some complex
transformational/whatever/git-like algorithm to make sense of the concurrent
edits possibly in a completely ordered and consistent fashion for all editors,
etc.....
So, as I said: first lock to simplify implementation, later add the further
functionality. It may be yet another way to have intermediate checkpoints
in the project.
>> knowing what was changed in each revision, it should be possible to
>> re-send only the affected/changed parts...
>
> That's a possibility, but one would have to store a history of
> revisions in case it is needed by someone else.
Yes, and it should not be a problem to keep in memory a few edits, till
the protocol ensures that all editors have the same vision and allows
for discarding them.
And, about netsplits, it would really be great if LyX could cache locally the
changes to be sent to the other side(s) while off-line, then update when back
on-line. That would re-use the edits history/revisions machinery.
But that may be yet another incremental feature, not to be addressed
immediately from the 1st day.
T.
