'Re: Collaborative editing / Versionning for koffice'

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

List:       koffice-devel
Subject:    Re: Collaborative editing / Versionning for koffice
From:       "Casper Boemann" <cbr () boemann ! dk>
Date:       2006-05-30 11:54:32
Message-ID: 039801c683df$d645eb90$2890a8c0 () FK13045
[Download RAW message or body]

That is exactly how I thought we should do it, and how it is described in the article \
                that Cyrille mentioned in the first mail (although he didn't like the \
                approach)
----- Original Message ----- From: "Robert Knight" <robertknight@gmail.com>To: "For \
developer's discussion about KOffice" <koffice-devel@kde.org>Sent: Tuesday, May 30, \
2006 1:30 PMSubject: Re: Collaborative editing / Versionning for koffice

> The GNOME Journal article is very interesting.  It seems like AbiWord> already had \
> a rather nifty structure under the bonnet for handling> changes to the document.  \
> Every change to the document is internally> expressed as an instance of a \
> "ChangeRecord" class.  For collaborative> editing purposes, all that needs to \
> happen is for the ChangeRecord to> be serialised over a network to other users \
> working on the document -> solving the diff problem.>> A similar framework was \
> introduced in KSpread in the 1.5 release (by> Stefan IIRC), although it isn't used \
> everywhere yet.>> On 30/05/06, Børre Gaup <boerre@skolelinux.no> wrote:>> Maŋ, \
> miessemánu 30. b. 2006 08.20, Boudewijn Rempt čálii:>> > On Tuesday 30 May 2006 \
> 01:43, Robert Knight wrote:>> > > Whatever we do, I think we should aim to keep it \
> fairly simple, and>> > > make sure that it gets used.>> >>> > Let's see... From my \
> personal experience, there are two levels of>> > collaborative editing that are \
> interesting:>> >>> > * change management _in_ the document, where it's possible to \
> discover >> > who>> > did what. For instance, I once wrote an article for \
> oreilly.net >> > together>> > with a co-author. We used OO (version 1) and the \
> editor used Word. >> > Changes>> > were visible in the document and could be \
> attributed to the responsible>> > party. This is very useful in many circumstances. \
> It's also part of>> > Fredrik's SoC project for KWord. We just need to make sure \
> that >> > Fredrik's>> > design is applicable to the other KOffice apps.>> >>> > * \
> real-time collaborative editing. When Sander and me are working on>> > Krita's \
> manual, it would be very useful if he in Delft and me in >> > Deventer>> > could \
> see the document, in a split window, me seeing him edit and he >> > seeing>> > me \
> edit. We would need a (preferably voice-based) chat channel next to >> > it>> > to \
> coordinate. Another example is something that happened yesterday:>> > Cyrille and \
> me were hunting bugs in the duplicate tool. We should have >> > used>> > mateedit \
> to see what we were doing, instead of throwing line numbers >> > and>> > changes \
> over irc.>> >>> This would indeed be a very good feature. In our project>> \
> (http://divvun.no/english.html) we write our meeting minutes>> \
> (http://divvun.no/doc/admin/meetings.html) in realtime using SubEthaEdit >> (we>> \
> use Mac OS X).>> The same feature would be very useful when writing letters, \
> articles,>> applications and so on, with word processor features.>> > I have never \
> needed collaborative editing outside wordprocessing or >> > coding,>> > although I \
> can imagine it would be useful for creating presentations, >> > too,>> > and for \
> diagramming.>> >>> > > It is worth noting that since only a small number of people \
> use >> > > KWord,>> > > it would be very helpful if any collaborative features \
> didn't require>> > > all parties to be using KOffice - that is the typical problem \
> I would>> > > expect to run into using a Microsoft application.    If any part of>> \
> > > your workflow relies on a non-Microsoft app then it all falls apart.>> >>> > I \
> > > think we shouldn't care about that. It's entirely unrealistic to >> > expect>> \
> > > > it to be possible to build a real-time collaboration feature that >> > \
> > > > supports>> > MS applications. We'd need to find how & why sharepoint works, \
> > > > get it >> > up &>> > running and then dodge all legal obstacles. I'm all for \
> > > > going it alone>> > here: let's first get it working, and then use the \
> > > > experience to build >> > a>> > protocol.>> >>> > Oh, and since Abiword \
> > > > already has collaborative editing, we should look >> > at>> > their \
> > > > implementation & protocol before designing our own.>> Yeah, being able to do \
> > > > this would be a showcase for open source and open>> protocols.>>>> Here is a \
> > > > link to their work:>> \
> > > > http://www.abisource.com/twiki/bin/view/Abiword/AbiCollab>> And an intro \
> > > > here:>> http://gnomejournal.org/article/31/gocollab----peer-to-peer-document-collaboration>> \
> > > > I also saw a movie on the net showcasing this work.>>>> -->> Børre Gaup>> \
> > > > _______________________________________________>> 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> 

_______________________________________________koffice-devel mailing \
listkoffice-devel@kde.orghttps://mail.kde.org/mailman/listinfo/koffice-devel

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