Realtime Collaborative Plain WikiText Editor

Last modified by Yann Flory on 2016/10/24 15:04

cogCollaboratively edit wiki pages in realtime with friends and colleagues
TypeXAR
Developed by

Caleb James DeLisle

Rating
Rate!
2 Votes
LicenseGNU Affero General Public License 3
Installable with the Extension Manager

Description

https://raw.githubusercontent.com/xwiki-labs/xwiki-labs-logo/master/projects/xwikilabs/xwikilabsproject.png

RtWiki is a Realtime Collaborative Editor for XWiki Syntax and scripts based on the Chainpad Realtime Engine and the XWiki WebSocket Integration extension.

In contrast to the RealTime Wiki Editor which is based on the Jupiter Operational Transformation Algorithm and implemented in the Google Web Toolkit, RtWiki is based on a radically new peer-to-peer design implemented entirely in Javascript and based on the Bitcoin Blockchain. While the Jupiter Realtime Editor had issues such as poor performance with large pastes, its fundamental limitation was its inability to handle multiple types of content because the server had to be aware of the content type. This realtime editor is based on Realtime Netflux Backend which is unaware of the document's content and merely handles registrations, de-registrations and the forwarding of messages, much like a chat server.

The RtWiki editor preserves the user interface of the original XWiki Wiki editor so with the RtWiki editor, you can smoothly transition from editing Wiki syntax alone to editing with other collaborators as a group.

rtwiki.png

If a document is currently being edited in Realtime, the normal "This document has been locked for editing" screen will appear but will allow you to join the Realtime Collaborative Session if applicable.

locked_join_rt.png

And of course if you are uncomfortable with realtime editing, you can click on the ALLOW REALTIME COLLABORATION checkbox to return to normal editing at any time and your preferences will be preserved.

allow_realtime_collaboration.png

Reminder for users: even though you are in a realtime session, you will still have to save your document when you are done editing it.

Reminder for admins: the RtWiki editor makes use of WebSocket which requires an open port from the users to the wiki, this port number and the hostname of the wiki can be specified in configuration, for more information see WebSocket.

Note for developers : If you want to check if realtime collaboration is allowed by a user, it is recommended to use the value stored in the localStorage. You just have to check if localStorage.getItem('realtime-disallow') is null or empty (realtime allowed) or equals to 1 (realtime disallowed).

Prerequisites & Installation Instructions

We recommend using the Extension Manager to install this extension (Make sure that the text "Installable with the Extension Manager" is displayed at the top right location on this page to know if this extension can be installed with the Extension Manager).

You can also use the following manual method, which is useful if this extension cannot be installed with the Extension Manager or if you're using an old version of XWiki that doesn't have the Extension Manager:

  1. Log in the wiki with a user having Administration rights
  2. Go to the Administration page and select the Import category
  3. Follow the on-screen instructions to upload the downloaded XAR
  4. Click on the uploaded XAR and follow the instructions

After installing with the Extension Manager, you will need to open the WebSocket Port as described above and restart the XWiki installation.

Release Notes

v1.22

Use the version 1.9 of Realtime Frontend

v1.21

Use the new Realtime Frontend with reconnecting websockets to re-enable editing after a connection failure

v1.20

Ability to use RTWiki with the Syntax Highlighting extension (CodeMirror)

v1.19

http://jira.xwiki.org/browse/RTWIKI-57
Refactor the application to use the new Realtime Frontend extension.

v1.18

fix http://jira.xwiki.org/browse/RTWIKI-53

v1.17

RTWIKI-52 unable to save if document contains non-ascii characters when certain Java plugins are present on host instance.

v1.16

RTWIKI-51 race condition in save and view eats save content.

Occasional deadlocks would cause the page to redirect before the save had completed.

v1.15

closes RTWIKI-50.

v1.14

RTWIKI-11: integrate changes which are made at the server side

using merge algorithm

RTWIKI-15: Do not autosave unless there have been actual changes to the text.

RTWIKI-29: Realtime should never override a save which bypassed the realtime session.

always merge, whether using buttons or autosave

RTWIKI-32: Hook the save button - merge on save

save and view/continue are _almost_ guaranteed to send ISAVE messages. only in the event of a network disconnection will other users be unaware of your having saved. related: RTWIKI-36

RTWIKI-33: On merge failure: keep our version OR theirs

settled by merge dialog

RTWIKI-34: Give Messages when merging

there are a variety of translatable messages, and a simple API for displaying them

RTWIKI-35: Use merge algorithm from inside of XWiki to do merge for RTWiki

RTWIKI-37: changes made during an asynchronous merge are overwritten

check if changes have been made, and discard merge until next cycle if so

RTWIKI-40: ISAVED messages are not recognized by chainpad

catch these messages before they are ever sent to chainpad

RTWIKI-41: don't merge if latestCommonAncestor and most recent version are equal

RTWIKI-42: in the event of a merge conflict, present a modal dialog

additionally, receiving an ISAVED message closes this modal

RTWIKI-44: don't save if live content is determined to be equal to the last saved content

determined by the server

RTWIKI-46: autosave cycles continue while the merge dialog is pending

set a flag while dialog is displayed, short-circuit during check if flag is present

RTWIKI-47: Only users which have made changes should autosave or settle merge conflicts

this cuts down on the number of merges the server performs. It also prevents displaying merge dialogs to non-editing users

RTWIKI-48: documents can wrongfully merge with themselves

if the merged document's content hash is found in the realtime history, the merge is ignored. This prevents merges which are reversions to earlier states

v1.13

Closes RTWiki-28, prevents unnecessary saves by comparing against the state of the last saved version (fetched via REST URL).

v1.12

Fixes http://jira.xwiki.org/browse/RTWIKI-30.

v1.11

Fixes http://jira.xwiki.org/browse/RTWIKI-29.

v1.10

http://jira.xwiki.org/browse/RTWIKI-26 If one person edits a document using WYSIWYG, another is incorrectly invited to "join realtime collaboration"

  1. attempt to get the language of the document from the html tag in case that the document is 'locked for editing'
    2. do not consider a realtime collaborative session as existing unless another user has registered

v1.9

fix http://jira.xwiki.org/browse/RTWIKI-21

v1.5

See: http://jira.xwiki.org/browse/RTWIKI-8?jql=project%20%3D%20RTWIKI%20and%20fixVersion%20%3D%20%271.5%27

v1.4

See: http://jira.xwiki.org/browse/RTWIKI-8?jql=project%20%3D%20RTWIKI%20and%20fixVersion%20%3D%20%271.4%27

v1.3

See: http://jira.xwiki.org/browse/RTWIKI-8?jql=project%20%3D%20RTWIKI%20and%20fixVersion%20%3D%20%271.3%27

v1.2

fixed http://jira.xwiki.org/browse/RTWIKI-3

v1.1

Added modal-popup to tell the user if he/she has been disconnected
Added lag meter to tell latency to the server and user-list to show who else is collaborating
Added auto-save every 30 seconds with save-announcements to prevent a document with many users from thrashing the server.
Updated the demo

Dependencies

Tags: realtime
Created by Caleb James DeLisle on 2014/02/03 23:13
    

Get Connected