Hi,<br><br>I am a KOffice developer, who intend to implement collaborative editing at some point in KOffice. For now I am doing change tracking.<br><br>I agree that GIT is not the way to go for real time collaborative editing.<br>
When speaking of "real time" collaborative editing, we are really talking about synchronous editing. The problem with several people editing THE same document at the same time  is concurrent edits. Two ways exists to handle this:<br>
<br>
- the pessimistic approach: real concurrent editing is not allowed. It means that each editor actually has a lock on the document (or a part of it). Before the lock is passed, the documents are synchronised.  This ensures that no incoherence are possible between the different editors. It usually is implemented by means of a token system. The main advantage of this system is that the state of each local replica of the document is guaranteed to be the same before every editing action. there is no risk of divergence between the different editors. The main drawback of this approach is latency. Since every user needs to wait for the token for his editing action to happen, the UI can become really unresponsive if there is a high latency between every workstation (due to network lag/ high number of users,...).<br>
<br>- the optimistic approach: every editing action is applied locally straight away and broadcasted to the other editors. Here we broadcast the editing action ("insert 'a' at pos 3"), not a diff of states (-abc;+abac). The actions received from the other editors are then transformed by the help of algorithm so they match the local state of the document replica. The advantage of this approach is that the editing keeps being responsive no matter what latency or number of users we have on the network. The main drawback is that consistency of the several replicas is not guaranteed. None of the current algorithm I know of can guaranty consistency (for more on this subject, search for "collaborative editing and operational transform" in google scholar). Furthermore, the current algorithm are pretty good when it comes to insert/delete of an atomic piece of text at a certain position. Operations working on a range are not properly handled by the current algorithm (that counts for formatting, or deleting a non atomic piece of text like a word).<br>
<br>Using Git for this would only be possible in the case of the pessimistic approach because a diff of state only makes sense when the states are guaranteed to match. And even in that case a broadcast of the actual editing action is probably cheaper.<br>
<br>
<br>One of my goal is indeed to implement collaborative editing in KOffice. However, I'd like to implement it so that particular protocols are backends to it. <br>Infininote is actually two things in one:<br>- a communication protocol, of which several different flavour exist: server/client architecture (infininote, jupiter,...) or distributed. For this I hope to be able to rely on KDE infrastructure (Telepathy?), but haven't looked very deep into this yet.<br>

- a real time editing algorithm using the optimistic approach, of which several different flavour exist: for infininote it is the adOPTed algorithm. Several others have been developed since to address quite a few of its limitations. Most are based on the OPerational Transformation (OPT) design, a couple have moved away from it (once again google scholar is your friend there, also look for "tombstone" with the aforementioned search terms).<br>

<br>As for the when it comes to form, the main problem here is manpower. I have a pretty good idea of what I'd like to implement. However, I am still not finished with change tracking in KOffice (which, as opposed to real time collaborative editing, is specified by ODF).<br>
<br>Pierre<br><br>
<br><div class="gmail_quote">On Tue, Jul 13, 2010 at 10:08 PM, Jos Poortvliet <span dir="ltr"><<a href="mailto:jospoortvliet@gmail.com" target="_blank">jospoortvliet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Thursday 08 July 2010 20:02:11 Robin Appelman wrote:<br>
> I might ask him if I see him tomorrow, I believe he's on akademy.<br>
><br>
> but for infinote the problem really is the server, the current one is<br>
> c(++)? so no use if we want to use php for deployability<br>
<br>
See if you guys can talk to the KOffice ppl about this - besides the java ODF tool they're also talking about this and probably have opinions on what/how when it comes to collaborative editing ;-)<br>
<br>
> On Thu, Jul 8, 2010 at 19:48, Andrei Nistor <<a href="mailto:coder.tux@ceata.org" target="_blank">coder.tux@ceata.org</a>> wrote:<br>
> > On Thursday 08 July 2010 20:31:32 Andrei Nistor wrote:<br>
> >> I don't think git is the right tool for realtime collaborative editing. I<br>
> >> would suggest implementing the infinote protocol [0], which would make it<br>
> >> compatible with kobby[1] and gobby[2]. I don't know if it's feasible to<br>
> >> implement this in PHP as I'm not really a PHP programmer, but if it's<br>
> >> possible it would be really nice.<br>
> >><br>
> > Further digging got me to the original specification for the infinote protocol<br>
> > [3] and a JavaScript implementation released under the MIT license [4]. The<br>
> > MIT license is compatible with the GPL, but I don't know if it's also<br>
> > compatible with the AGPL. Maybe someone knows Adriaan de Groot from the kde-<br>
> > legal team and could ask him to shed some light on the various licenses<br>
> > compatibility with the AGPL.<br>
> ><br>
> >> [0] <a href="http://gobby.0x539.de/trac/wiki/Infinote/Protocol" target="_blank">http://gobby.0x539.de/trac/wiki/Infinote/Protocol</a><br>
> >> [1] <a href="http://kobby.greghaynes.net/" target="_blank">http://kobby.greghaynes.net/</a><br>
> >> [2] <a href="http://gobby.0x539.de/trac/" target="_blank">http://gobby.0x539.de/trac/</a><br>
> > [3] <a href="http://infinote.org/" target="_blank">http://infinote.org/</a><br>
> > [4] <a href="http://jinfinote.com/" target="_blank">http://jinfinote.com/</a><br>
> > _______________________________________________<br>
> > Owncloud mailing list<br>
> > <a href="mailto:Owncloud@kde.org" target="_blank">Owncloud@kde.org</a><br>
> > <a href="https://mail.kde.org/mailman/listinfo/owncloud" target="_blank">https://mail.kde.org/mailman/listinfo/owncloud</a><br>
> ><br>
><br>
><br>
><br>
><br>
_______________________________________________<br>
koffice-devel mailing list<br>
<a href="mailto:koffice-devel@kde.org" target="_blank">koffice-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/koffice-devel" target="_blank">https://mail.kde.org/mailman/listinfo/koffice-devel</a><br>
</blockquote></div><br>