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

List:       koffice-devel
Subject:    Re: Collaborative editing / Versionning for koffice
From:       "Robert Knight" <robertknight () gmail ! com>
Date:       2006-05-29 23:43:26
Message-ID: 13ed09c00605291643n3390f4m9047c74152ef50db () mail ! gmail ! com
[Download RAW message or body]

Hi Cyrille,

Before we even think about how the system might be designed, we need
to deal with the use case.  KDE apps have a habit of ending up with
powerful features that don't solve real world needs very well because
the most important aspect of the design ("what the user needs") was
glossed over.  Recent frustrations trying to use the KDE CD ripping
program (I cannot remember its name) brought this to light only too
well.  It offered complete control over every little detail and very
detailed progress information, but getting the basic functionality out
of it proved difficult.  By contrast the GNOME app (Sound Juicer) just
required me to insert a CD and press one clearly labelled button,
thereby satisfying the most important use case.

Your post mentions QtNetworks, X dependencies, algorithms to manage
and merge changes etc.  I think this is much too low-level for the
moment.
I have a problem with the newspaper example as it just doesn't strike
me as a realistic application of KWord.  This then raises some
questions:

1)  Where would collaborative features be useful? - We need a few
detailed use cases here, ones which are at least partly based on real
world experience.
2)  What collaborative features do the competition have - can we
improve on them?

Whatever we do, I think we should aim to keep it fairly simple, and
make sure that it gets used.

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.

Regards,
Robert.


On 29/05/06, Cyrille Berger <cberger@cberger.net> wrote:
> Hi all,
>
> I want to start a discution about adding collaborative editing/versionning in
> KOffice 2.x (note that x might be x >=1, but I had rather have x=0 even if
> it's not feature complete and supported by all apps). As those two features
> are closely related, I do think that we can provide support for both of them
> at the same time. (And with the design about which I am thinking we might
> even get some sort of ressource server for free ;) )
>
> ** Versionning
> Versionning is part of proposed google soc, so I will let the student take
> care of it, but there is a lot in common between versionning and
> collaborative.
>
> ** Collaborative editing
> The collaborative edition will need a small server, and I see at least two use
> case, one involving working on a single document, and the other one need
> collaboration between all koffice applications.
>
>  - server
> It needs to be gui independent (relying on QtNetworks but on nothing that
> would bring an X dependency) and really easy to use, minimal configuration
> should be required, a directory for where to save files and a port number
> (something working like verse of the blender project
> http://verse.blender.org/cms/Overview.573.0.html, possibly using it if I
> understand how it is supposed to work)
>
>  - work on a single document
> there are two approaches, one involve looking (automaticaly or not) and the
> other one use a powerfull algorithm to merge changes (like describe in An
> Integrating, Transformation-Oriented Approach to Concurrency Control and Undo
> in Group Editors by Ressel, Nitsche-Ruhland and Gunzenhäuser), I dislike the
> second possibility, and there for I will let Casper defend it.
>
> So for the first method, I will use the example of a document, for instance a
> yearly report from a commercial team. The document is devided in chapter,
> section, paragraph... Each one of them can be locked either because the
> manager has given someone the responsability to work on that part or because
> someone else is working on it and hasn't yet commit the changes.
>
>  - multi-document work and sharing
> The scenerio I have selected to demonstrate how it should work is the edition
> of a newspaper, I think it would allow to demonstrate how I think we should
> design collaborative work in koffice.
> At the center of the creation of a newspaper is someone in charge of the
> layout, he will need to receive the collaboration of everybody.
> kword would be used by journalists to write articles.
> Krita by people retouching pictures. Karbon/Kivio by people creating the nice
> graphics we see on newspaper to explain a complex situation. And so on.
>
> The contribution from everybody is shared through the server which will warn
> the clients of the availability of an update. And the layout guy will have
> the ability to see differences and agree to apply them, automaticaly updating
> the newspaper.
>
> --
> --- Cyrille Berger ---
> PS we might want a cool code name too ;P so that no one would understand about
> what we are speaking ;)
> _______________________________________________
> 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]