[Owncloud] Suggestions

[Pierre Stirnweiss]

On Wed, Jul 14, 2010 at 10:43 PM, iberlynx <iberlynx at lavabit.com> wrote:

> Hi,
>
> you say git is not the way to go because you only consider it in the
> pessimistic approach. But have you thought of using git or some similarly
> powerful diff engine with an optimistic approach?
>
> What I am saying is that a git based solution needs the pessimistic
approach to work. See below:


> Let me give you my proposal:
> Every user action be it a single character change or a block change or a
> formatting change is automatically git-committed and git-pushed to the other
> users, which would automatically git-merge the changes as git does so well.
> So no locking would be required, hence no latency problem.
> (This would additionally solve the problem you stated with non atomic
> changes!)
> The only obstacle that I foresee is that IIRC git doesn't merge changes on
> the same line, but I'm sure that there's a way to tailor git's algorithm for
> this specific use-case!
>
> Am I just being my usual self, and this is a crazy idea? Or does it make
> sense to you as well?
>
> The problem is that git merge works pretty well when the original state of
the merged documents are the same (or at least very similar). It requires
that a particular line can be found (if not at the indicated position) by
comparison of the surrounding lines, if it cannot find (or does not have)
this "context", then the merge fails.
Using an optimistic approach environment, it is guaranteed that the state of
each local replica are different, because the local changes are incorporated
straight away in the document. This means that, for the very vast majority
of the editing actions (actually down to each key stroke), you will have the
following done on each of the other replicas:
a git merge is processed, which could have to scan the document around the
specified line number (if the local editor added a line before). Now:
If the local editor modified the same line, or the scan above did not
succeed, we have a merge conflict. In case of a merge conflict, git needs it
to be manually solved in order to complete the merge operation.
Now keep in mind that until the merge request is fully processed, the local
user cannot continue his own editing (because the git commit cannot be
done). Also keeping in mind that as far as text processing is concerned, a
line (in the git sense: everything until a new line char) is actually a full
paragraph.
So to sum-up: in case of git with the optimistic approach, you would be
handling a lot of merge conflict between each of your key strokes. And even
if there are no merge conflict, your user interface will be blocked during
the whole merge operation of each of the other editor actions. While you
feel that the git algorithm is really good, it is still way too slow to be
acceptable in between key strokes of someone typing text.

There is a further problem, which actually also disqualify git (whatever the
approach) when implementing real time collaboration on applications relying
on position based textCursors (Qt scribe engine, but if I understood
properly the blog posts, also Kate internal cursor stuff):
Let's say your cursor points at position 10 of your text. A change from
another editor is merged (let's say no merge problem happened), before that
position. If the change modifies the char count, your position 10 becomes
invalid and needs to be recalculated. In order to do this you could use the
git diff to compute what the difference is. But doing this you are basically
reconstructing what the operation was. Basically the workflow of your
software would be: editing action -> state diff -> transmit state diff ->
merge state diff -> compute editing action from state diff -> update cursor
position.
It is far more logical to transmit the editing actions.

Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20100715/2f90ca6c/attachment.html>