[Owncloud] Suggestions

[Pierre Stirnweiss]

A couple of points to keep in mind:

Locking based solutions:

- a locking based solution (pessimistic approach) provides the highest
security in terms of convergence of the document, as well as the easiest
implementation of all the possible editing actions. Because every editing
action broadcasted to the different replicas are guaranteed to be valid,
since the initial state of the document is identical. Provided that a small
amount of users work together on a low latency network, the locking would
probably not hinder usability too much.
- the granularity of the locking depends on the document representation, as
well as the editing mechanism. All parts of the document in which an edit
can affect the state of the replica's editing should be locked. In a cursor
based editor, this means that all parts of the document which affect the
cursor should be locked. For example, Qt has a cursor position throughout
the whole QTextDocument. This means that the whole QTextDocument has to be
locked. One can conceive a locking mechanism based on the editing action.
For example, whereas the whole QTextDocument has to be locked in the case of
an insert (because it affects the cursor positions), it is possible to limit
the lock to a QTextBlock for paragraph formatting.

Non locking based solutions (optimistic):

- this is clearly the way collaborative editing is moving to. However, this
is a highly evolving field. New algorithm are rapidely developping. This
means that extra care should be taken not to tie an implementation to a
particular algorithm too deeply.
- for now, not all editing actions are guaranteed to preserve consistency of
the replicas (in all situations) by the current algorithm. Current
frameworks therefore foresee some sort of synchronisation at regular
interval, in order to correct the replicas.


In general:

- there have been quite a few discussions about updating XML structures when
speaking of real time collaboration. I can't speak for OOo or other editors,
but KOffice does not hold the document as an XML structure when editing. The
ODF (XML) is created on saving. Real time collaboration using XML deltas,...
would for KOffice (at least) require ODF/XML serialisation/deserialisation
for every editing action.
- as mentionned in my other email about Git, I don't think that a state base
diff is the way to go to implement real time collaboration. At least in the
case of cursor based editors, because the actual operation would in any case
have to be computed from the different states in order to update the cursor.
It is therefore much cheaper to broadcast the actual operation done.
- undo/redo should be kept in mind. If my document is the result of: myOP1,
otherOP1, myOP2, otherOP2, otherOP3, what should be undone if I press undo?
otherOP3 (the last overall operation, but not one I did)? or myOP2 (my last
operation, but not the last modification of the document)? There is also a
technical side on this question, as certain algorithm allows to undo
operations in any order, others do not. Furthermore, in case of an
optimistic implementation, the order of execution of the editing operations
are not necessarily the same in each replicas.


Now, with regards to the Duchain proposal, I have to say that apart from
knowing that it is used for the context highlighting in KDevelop, I have got
zero clue about what it is. I can't comment on this then.

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