You are here: Foswiki>Development Web>SynchroEdit (30 Dec 2009, PaulHarvey)Edit Attach

SynchroEdit

"SynchroEdit is a browser-based simultaneous multiuser editor, a form of same-time, different-place groupware. It allows multiple users to edit a single web-based document at the same time, and it continuously synchronizes all changes so that users always have the same version."

"SynchroEdit's main editor is fully WYSIWYG, dynamically displaying bolds, italics, underlines, strikethroughs, with various justifications, indents and listing styles as an author inputs them. SynchroEdit also supports a simple, text-only editor for more basic documents. To clarify the multiuser experience, the editor window clearly depicts every user's changes in a specific color and also marks where each user is currently editing with a colored flag listing the user's name."

Discussed at WikiSym2005

-- MartinCleaver - 17 Oct 2005

Discussions

Tonight I saw a demo of SynchroEdit by author ChristopherAllen. BTW, Christopher also runs Skotos Tech, which has a large internal TWiki deployment. Some impressions on SynchroEdit:

Nice experience; useful tool on a conference call
Each person's text is color coded
You see simultaneous edits on the same page
If two person edit the same line, the second person gets a warning that his edits are blocked for a few seconds (technically it is possible to let them edit the same line, but it is a too confusing experience for the user.)
There is a right pane that shows the list of concurrent users (color coded), and a chat window (to discuss the document without cluttering the document)
At the end of the session you get an e-mail with the page content
Currently only works on FireFox 1.x and 2.0 using DOM; IE support would be possible if an Active X plugin is created (or if IE implements support for mutation events)
Technically, when in synchro edit mode:
- A page is delivered, keeping the connection open (page never finihses loading)
- This allows the page to receive additional data (e.g. events from other participating users via the server)
- Events manipulating the DOM are sent to the server; the server sends them to all participating users
Server side software is done in Java
Licensed under open source (LGPL and MPL)
Test implementation done for Kwiki (WYSIWYG mode) and MediaWiki (wiki markup mode)

Is anyone interested in creating a SynchroEditPlugin for TWiki? I think this would be a useful enhancement for the workplace: The idea is to use the editor just for special purposes, such as to work on meeting minutes, or to flesh out a rough spec of a project.

Ideas on user interface:

New "Synchro Edit" button on TWiki pages
Once in synchro edit mode, gray out other edit buttons and attach button, and show this message on top:
"This topic is currently edited synchronously. Do you want to join the edit session?"
Once in synchro edit mode you can edit content in WYSIWYG mode, do a snapshot save, leave without save, and cancel edit session.

-- PeterThoeny - 07 Dec 2006

Implementation thoughts

My time is limited, but I'm as excited as the guy next doors to see SynchroEdit integrated into TWiki, and will do whatever I can to help you guys out. In particular, since SynchroEdit is still not at v1.0, I am more than willing to discuss changes in the system itself that would ease incorporation into TWiki or other systems, so don't hesitate to bring up suggestions or comments on how things are handled. I'll also gladly help give advice or explain stuff that seems confusing.

The current implementation into MediaWiki was more a proof-of-concept than it was an actual implementation, but it gave me a good idea what puzzle pieces are needed to make everything work. It's hard to give an estimate on the amount of time it would take to put this in place into TWiki, but my guess is it would take "less than a week", presuming that week was pretty dedicated to the implementation. Possibly a few days only, but I'm not very versed in TWiki-gore, so I may not be able to help out too much on the TWiki-end of things. In any case, the following issues arose in my implementation and will doubtlessly arise in yours:

Authentication

When a user connects to the SynchroEdit service, the user has basically left the TWiki system, and there is no guarantee that the user is actually authenticated. In the MediaWiki implementation, I solved this by generating an MD5 hash of the user's ID + the user's password and storing that as a cookie in the user's browser. (SynchroEdit itself detects these cookies if they are named correctly, i.e. 'seuid' and 'sesid'.) The authentication was then made via the ESPI hook for authentication, which confirmed that the user ID + password hash matched the session ID.

If I recall right, TWiki is written in Perl. The ESPI system is a super-simple "relay" for external functionality, and I could probably write a Perl version of it for you (it's currently in PHP only). More info about this system is here: http://wiki.synchroedit.com/index.php/ExternalServicePOSTInterface

Saving

In traditional wiki-style editors, users modify content while keeping the page locked for a specified amount of time (an hour in TWiki, I think). When the user is done editing, they click a Save button which transports the user to the updated/saved version of the same page. In a synchronous session, this turned out to be a rather clunky behavior. Synchronous sessions tend to draw out for sometimes several hours, and people like to save the document occasionally, just like they save their OpenOffice documents regularly, to avoid loss of data. The approach I took here was to make Ctrl+S and "Save page" do just that; save the page but keep the user in the session. I added a new button called "Leave session without saving" which people could use when they felt finished, and an "Abort session" which gives users the option to cancel the editing entirely. (A current flaw in my proof-of-concept that needs a fix before it can be deployed is that anyone can abort a session -- ideally, only the initiator or an administrator should be able to do such a thing.)

Beyond that, saving also happens via ESPI. Two hooks called 'save-document' (for Ctrl+S and/or "Save page and continue editing" button) and 'terminate-action' (for "the last user left the session") are basically copies of each other. The system sends HTTP POST arguments such as $document, $content, $contributors, $startdate, $chat, etc. to these hooks, and beyond that, it's up to the individual hooks to take it from there. In the MediaWiki case, the hooks simply perform the SQL queries for saving, as if the document was saved by a regular user. The MediaWiki implementation is currently not "WYSIWYG", but still handles some simple conversions (H1's turn into = content =, B's turn into '''text''', and so on -- this would obviously be different in TWiki due to syntax differences). What does have to happen though is that BR's are turned into \n.

Loading

When loading/initiating a synchroedit session, the wiki must do some minor adjustments to the content. Since wikis are non-WYSIWYG by design (or at least in my proof-of-concept, that was the case), and synchroedit works on XHTML documents, newlines in the wiki-text have to be converted into BR's. Beyond that, it should work as-is.

Locking

Nigh on philosophical, but locking becomes an issue. If I am SynchroEditing a TWiki topic for 10 hours straight, for 9 of those hours, it will appear as if the topic is untouched to everybody else, regardless whether we save occasionally or not. One idea would be to refresh the 1-hour lock every time the topic is saved (not a bad idea at all). Another idea would be to use notifying (see below) to make people aware of a SynchroEdit session for the topic they're about to edit.

Notifying

Although it's possible to join an existing synchronous session just by initiating a synchroedit session for the topic, it's pretty meaningless if the topic doesn't announce the synchronous session in progress. I solved this by creating a whole new SQL table called "synchroedit" which contains information about the currently existing sessions. Whenever a user visited a topic, the system checked if that topic existed in the table of sessions. If it did, the system connected to the synchroedit server and asked if the session was in fact still in progress. If it is, the system puts out a message akin to "This topic is being synchronously edited by [initiator]. Click here (link) to join this session."

I also added a new special page called "SynchroEdit Sessions" which showed a table of existing sessions in the system.

-- KalleAlm - 11 Dec 2006

Why is the idea to use the editor just for special purposes ? If the editor is WYSIWYG then why not make it the default interface with the anticipation that wiki usage will at times crecendo into spontaneous sessions of multi users working together on the same topic at the same time ? I love it!

-- KeithHelfrich - 08 Dec 2006

I tweaked some of PeterThoeny's content above (e.g. ?? => MPL, and added comment about IE + mutation events in parentheses).

-- KalleAlm - 08 Dec 2006

Thanks Kalle for offering your support. Lets see if you get our support! This is also a possible StudentProject.

Keith: AFAIK, SynchroEdit's WYSIWYG editor has just basic functionality needed for taking notes during meeting. I think misses more advanced/standard features such as table editing. A simple single user edit & save is easier & faster than an enter/join SynchroEdit session, checkpoint save, save & leave (but others continue), etc states. So there is room for both edit modes.

-- PeterThoeny - 12 Dec 2006

Ultimately, it should switch you over to synchronous mode if somebody else tried to edit a topic you were editing. Though that sounds like a "version 2.0 deal".