Place for Brain Storming.

Undo/Redo

Undo and Redo are worth discussing in their own right separate to standard editing because many transformation algorithms do not take this problem into account and a considerable amount of effort has been made to create algorithms that cater for this problem. Whatever algorithm is chosen it should support Undo and Redo without additional research.

How should it be handled? Should a sent operation be able to be undone by anyone? by authorized people? by the user only? How should the logs show it?


==__Communication__==
One thing that would be nice to have sorted out is communication which is logically apart from the actual collaborative editing but watching someone make changes without having a way to interject or compare notes is a hollow victory at best. The transport seems to lend itself to XMPP which may need a lightweight server. For KDE a [[http://decibel.kde.org|Decibel]] transport makes sense. At the very least the user should be able to talk with others who are working on the same document.
It would be nice to have it tie into a list of possible people to collaborate with. This should be both explicit (a users list of contacts) as well as discoverable (a new worker in the office should get a list of people they can work with)

Grouping

Within communication it would be helpful to have the ability for the user to set groups (possibly also a option to do it server side for a heavy server) so that if you are working with collections of people's or interests you can have the collective changes done by those people as single highlights. An example would be having legal, technical and management working on a single document. You could group the people from each interest into one group and elect to have all changes made by that group have one colour or if needed have all the people from that group have hue shifts of a single colour. All legal changes are some form of yellow all technical some form of purple and all management some form of red.([[skreech2]])
 

Multiple Projects

Being able to have multiple connections open and differentiate not only who is working on what but when they were last active would be very useful.

Peer Discovery

There are 2 scenarios for peer discovery which need consideration: Local network and internet

Local network

Most modern OS'es have Zeroconf support for the local network thus Zeroconf should be supported.
 

Internet

To enable connections over the internet an easy connection mechanism using URL's should be provided. Ideally this mechanism should be integrated into Instant Messaging clients.

Server

There should be a heavy duty server that will be used by businesses or large scale installs/projects. This can also be used at extended brainstorms or hackfests. Conventions and new open source projects should also benefit from a permanent long term heavy lifting server. However each client should also have a very lightweight server that allows for quick collaborations as well as facilitating discovery by other people. The full details of what each should bring with it's role can be discussed at the [[Server]] page 

Applications

Applications that can be enhanced:
Kate->KDevelop, Quanta, Yzis
KWord
KDissert
KEdit
KWrite

Krita

Karbon