[Owncloud] Suggestions

Wed Jul 14 09:17:47 UTC 2010

Hi,

I am a KOffice developer, who intend to implement collaborative editing at
some point in KOffice. For now I am doing change tracking.

I agree that GIT is not the way to go for real time collaborative editing.
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:

- 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,...).

- 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).

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.

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.
Infininote is actually two things in one:
- 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.
- 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).

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).

Pierre

On Tue, Jul 13, 2010 at 10:08 PM, Jos Poortvliet <jospoortvliet at gmail.com>wrote:

> On Thursday 08 July 2010 20:02:11 Robin Appelman wrote:
> > I might ask him if I see him tomorrow, I believe he's on akademy.
> >
> > but for infinote the problem really is the server, the current one is
> > c(++)? so no use if we want to use php for deployability
>
> 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 ;-)
>
> > On Thu, Jul 8, 2010 at 19:48, Andrei Nistor <coder.tux at ceata.org> wrote:
> > > On Thursday 08 July 2010 20:31:32 Andrei Nistor wrote:
> > >> I don't think git is the right tool for realtime collaborative
> editing. I
> > >> would suggest implementing the infinote protocol [0], which would make
> it
> > >> compatible with kobby[1] and gobby[2]. I don't know if it's feasible
> to
> > >> implement this in PHP as I'm not really a PHP programmer, but if it's
> > >> possible it would be really nice.
> > >>
> > > Further digging got me to the original specification for the infinote
> protocol
> > > [3] and a JavaScript implementation released under the MIT license [4].
> The
> > > MIT license is compatible with the GPL, but I don't know if it's also
> > > compatible with the AGPL. Maybe someone knows Adriaan de Groot from the
> kde-
> > > legal team and could ask him to shed some light on the various licenses
> > > compatibility with the AGPL.
> > >
> > >> [0] http://gobby.0x539.de/trac/wiki/Infinote/Protocol
> > >> [1] http://kobby.greghaynes.net/
> > >> [2] http://gobby.0x539.de/trac/
> > > [3] http://infinote.org/
> > > [4] http://jinfinote.com/
> > > _______________________________________________
> > > Owncloud mailing list
> > > Owncloud at kde.org
> > > https://mail.kde.org/mailman/listinfo/owncloud
> > >
> >
> >
> >
> >
> _______________________________________________
> koffice-devel mailing list
> koffice-devel at kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20100714/5aa2102c/attachment.html>