A couple of points to keep in mind:<br><br>Locking based solutions:<br><br>- 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.<br>
- 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.<br>
<br>Non locking based solutions (optimistic):<br><br>- 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.<br>
- 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.<br>
<br><br>In general:<br><br>- 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.<br>
- 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.<br>
- 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.<br>
<br><br>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.<br>
<br>Pierre<br>