[Owncloud] Suggestions

Wed Jul 14 20:43:38 UTC 2010

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? 

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?

On Wednesday 14 July 2010 10:17:47 Pierre Stirnweiss wrote:
> 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
> >
> 