Multiuser Edit

Currently DokuWiki locks a page once someone starts to edit it. This idea is about adding a feature where two or more people could simultaneously edit the same page similar to the Google Docs or Etherpad.

This feature requires some kind of backend server. It could be implemented taking the rather simple mobwrite library which uses a Server written in Python. We could provide a public server backend at DokuWiki.org (or appengine) for people who can't run the server themselves. There is also a fork of mobwrite at GitHub that uses the Tornado Web Server. As the project doesn't seem to be really active anymore we should plan maintaining it ourselves if we decide to use it.

• The backend technology should be lightweight and low on dependencies to be installed easily on cheap hosting and/or cloud servers

This feature should be implemented as plugin or be optional.

The user who starts editing a page should be able to allow or deny the initialization of a multi-user session.

• Whoever starts the edit session becomes the “session master”
• The session master can allow others to join
• When the session master leaves, the page is saved under his name, but the editing session continues
  • On save, additional users who contributed to the session are mentioned in the edit summary
  • The next person who joined after the old session master becomes the new session master
• Editing ends when all participants left

As a simple integration of mobwrite is trivial the main task of this project should be to provide a nice user interface and to really integrate with the editing process in DokuWiki.

Some points you should take into consideration:

• Generate truly random ids that are still somehow connected to the wiki (e.g. add a unique identifier and use the sha1sum of that)
• Hide/extend the lock screen, take care of the save process (i.e. only remove the information about the editing session when the last one has left it)
• Handle section edits! When a single section is edited still the whole content is present in the browser (DokuWiki uses hidden inputs for that) so we could still sync the whole page when just a section is edited.
• What happens when a client goes offline and comes online again? (Find out if/how mobwrite handles that.) And what happens when all other participants have closed the session in the meantime?

Some ideas for the user interface:

• Display a list of participants
• Display the cursor position of all participants (e.g. with a div in the background) and highlight changes of different users
• Provide an optionally visible chat area

If you want to implement this as part of the Google Summer of Code please provide more detailed descriptions how the editing process should look like, perhaps some drafts of the user interface and also more detailed ideas how you'll implement the different features. Feel free to suggest different synchronization backends if you don't like MobWrite.

• Implementing a Syntax-Highlighting JavaScript Editor—In JavaScript - an article about implementing syntax highlighting in JavaScript, might contain useful information for highlighting the text written by different authors in a session - and the follow-up: http://codemirror.net/internals.html (though that's probably not the best approach for these needs)
• EditArea - the code editor in a textarea - an opensource browser-based code editor that is relatively simple (a textarea is in the foreground and semi-transparent, the actual highlighting is done with a copy of the text in a div behind the textarea - this approach might be another idea how to highlight certain parts of the text.

• JavaScript as a major part of your work will be to implement certain features of the sync client
• XHTML and CSS as you need to create new parts of the user interface for the editing process
• PHP as there is also some server side part involved (i.e. the session and lock handling)
• Some bits of Python in the case of mobwrite as the server backend might need to be fixed/extended.

Medium: Synchronizing stuff isn't easy so expect some difficulties like the scenarios that are outlined above. There are just a few parts of DokuWiki (locks, saving, drafts) concerned so understanding DokuWiki isn't the issue.

The following people volunteered to “mentor” any new developers taking up this task by answering questions, giving tips and reviewing code:

• Andreas GohrAndreas Gohr
  andi
  
  Berlin Germany
• Michael HamannMichael Hamann
  Michitux
  
  Karlsruhe, Germany
• Adrian LangAdrian Lang
  adrianlang
  
  Berlin

• http://www.freelists.org/post/dokuwiki/GSOC2011-Multi-User-Edit

We have been using a combination of DW and Google Docs or Piratepad during live or Skype work-sessions and realtime editing would be a great addition to DW. Would be more than happy to do beta testing. — Thomas WingateThomas Wingate
twingate

Göteborg, Sweden 2011/02/13 18:48

The need for python limits it's use. Is it possible to create a temporary page when a second user request to edit a section? So instead of locking him out he will be notified that another person is working on another section, and let him chose how to merge the two revisions and a link to a diff comparison could be provided. if both were working on different sections, the system should place every change on it's place with no problem. — damascenedamascene

2011/02/16 01:16

Python is only needed for the backend, as explained above there could be a public server at dokuwiki.org that can be used by everyone who can't host his own one. Merging sections is subject of the merge idea. I think for this idea we should assume that always the whole page is edited and otherwise either the page is locked like now or the hidden parts are synchronized, too. — Michael HamannMichael Hamann
Michitux

Karlsruhe, Germany 2011/02/15 23:45