[Konversation-devel] [Bug 130587] New: Synchronous, peer-oriented, concurrent live document editing, via IRC (or IM)

[Robert Moore]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=130587         
           Summary: Synchronous, peer-oriented, concurrent live document
                    editing, via IRC (or IM)
           Product: konversation
           Version: unspecified
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: konversation-devel kde org
        ReportedBy: rdm docreate net


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.