[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: [Owncloud] Suggestions
From:       iberlynx <iberlynx () lavabit ! com>
Date:       2010-07-14 20:43:38
Message-ID: 201007142143.39382.iberlynx () lavabit ! com
[Download RAW message or body]

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@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@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@kde.org
> > > > https://mail.kde.org/mailman/listinfo/owncloud
> > > > 
> > > 
> > > 
> > > 
> > > 
> > _______________________________________________
> > koffice-devel mailing list
> > koffice-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/koffice-devel
> > 
> 

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]