Bug 130587 - Synchronous, peer-oriented, concurrent live document editing, via IRC (or IM)
Summary: Synchronous, peer-oriented, concurrent live document editing, via IRC (or IM)
Status: RESOLVED INTENTIONAL
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-11 00:56 UTC by Robert Moore
Modified: 2006-07-12 00:56 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Moore 2006-07-11 00:56:53 UTC
Version:            (using KDE KDE 3.5.3)
Installed from:    Ubuntu Packages
OS:                Linux

This report is about document synchrony between peers for live concurrent editing of parallel local documents (eventually with arbitrary MIME types). The benefit of such synchrony is non-linear editing of documents and code, while at the same time recording a conversation relevant to the thinking that went into their development. The same data performs multiple functions.

Scripts, or native application routines would parse input received and return changes to a document GUI. I would like to pipe chat sessions to scripts arbitrarily from Konversation or Kopete. Because Konversation stores its logs on disk, it seems a good candidate for efforts such as these. The program would have in-built controls to prevent (or at least keep to a minimum) chatroom flooding.

Below is an idea of the stages or routines within the application loop, for an extra front-end to Konversation. This would probably work with plugin scripts, but would undoubtedly be faster and better once coded natively. This idea is posted here in the hope that it will encourage discussion and action by interested parties. Additionally, votes are less easy to quickly track on a mailing list compared to here at bug.kde.org.

As always, you are invited to vote for this bug and contribute ideas and code!

::Functions described & Process ordered::
=========================================

Monitor (remote-oriented):

1.  Tail logs for changes.
If necessary, seek match to last check, from and with the end of the file.

2.  Parse diffs.

3.  Present changes to the user.

4.  Fork on rejected changes.

Configuration options:
-Automatically accept (passive).
-Automatically reject (forker).
-Always ask (invasive detail).
-Periodically ask (productivity comparison).
-Per bookmarks (section monitors).

Also allow "undo fork". That is, log, but do not implement specified changes.

5.  Store diffs per fork, and per user.

6.  Show views (optional), per fork, user, users, section.
This includes quick and easy switching of these views.

Local edits (UI & configuration):

7.  User makes changes

Configuration options:
-Automatically submit (active, near realtime)
-Manual submit (revision checks)
-Interval submit (semi-automatic, productivity comparison)

8.  Generate diffs.

9.  Optionally parse diffs to unambiguous prose equivalents.
Configuration options:
-Language
-Verbosity

10. Store diffs locally, parse them.

11. Send the diffs or their parsed equivalents to peers or the chatroom.

Configuration options:
-All connections possible, including DCC, which for more than 2 collaborating peers will need to synchronise and negotiate content individually with no single chatroom target. This implies send the same or similar messages to multiple recipients.

12. Fork if rejected
Allow logged undo options to quietly re-synchronise, or display parallel views.
Comment 1 Eike Hein 2006-07-12 00:56:58 UTC
Konversation is dedicated to being a user-friendly IRC client for KDE, and we presently have no intentions of expanding that agenda to cover a collaborative editing suite. That said, we're certainly interested in creative use of the application and will try to do our best to improve the facilities we offer for third-party add-ons. When you have distilled your ideas into specific requests on how to aid your enterprise (which don't conflict with what Konversation aims to be), please file seperate and concisely written reports on them. In the meantime, the konversation-devel mailing list may serve as a place for discussion, and you may find the developer resources in the Konversation Wiki of interest.