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

List:       koffice-devel
Subject:    Re: Collaborative editing / Versionning for koffice
From:       Børre_Gaup <boerre () skolelinux ! no>
Date:       2006-05-30 9:23:01
Message-ID: 200605301123.01527.boerre () skolelinux ! no
[Download RAW message or body]

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/AbiCollabAnd an intro here: \
http://gnomejournal.org/article/31/gocollab----peer-to-peer-document-collaborationI \
                also saw a movie on the net showcasing this work.
-- Børre Gaup_______________________________________________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]