July 05, 2012
I feel pretty bad for not having written about my Google Summer of Code project that I’m undertaking this summer for Wikimedia Foundation for prototyping collaborative editing feature for the new under-development VisualEditor(wysiwyg). Its been a while since I was selected, and started working on it, so I won’t go into discussing the story around how I got started on it. But, I would like to discuss about the present state of the project, where its heading and also a bare working demo of the code produced so far.
So the VisualEditor project is a wysiwyg editor for MediaWiki, designed from scratch keeping in mind the complexities of the Wikitext mapping to HTML and data structures suitable for inline editing. The changes to the text in VisualEditor are in the form of transactions. There are transactions for insertion/deletion of text as well as applying formatting attributes to a portion of text. So most of the collaboration thing revolves around these transactions. There is a collaboration server which listens for new connections from clients who requests to initiate an editing session. A client module establishes connection with the server, and listens to the changes made in the document and translates the resulting transactions to the server. A thing that should be noted here is, the project is under Phase 1 which would support only one client who publishes changes to the server’s document and other connected clients simply listen to these changes and apply them in their local documents. Phase 2 would support multiple publishers which would bring in conflicts and concurrency issues and perhaps measures to fight with them.
So, there is a small list of things which have been done so far -
ve
object.The collaboration server is a Node.js based server, which uses socket.io for making persistent connections with the clients for realtime communication. The client module binds against the server’s API which is laid in terms of the socket.io events defined in the server. All the VE functionality is accessed through a binding module which exports a top-level ve
object much like the ve
namespace is used on the client-side. The server can parse the wiki pages internally using the parser modules and also can fetch the parsed HTML output from an external parsoid service over HTTP. As of now, an external parsoid service is used for scalability until something better can be figured out.
Authentication
Some code has been written for handling user authentication on the socket connections level but is not functional right now. Also, due some review on the proper technique to do it, its deferred for a little later.
Editing control transfer
Right now editing control is given to any user who joins when there is no client with publishing right is connected to the server on a same document. A publishing user before disconnecting might want to transfer the editing control to a client which is already connected as non-publishing client.
Transactions buffering
Right now every transaction is fired towards the server as it is generated in the VisualEditor. This would be quite a network activity. So, there would be some buffering and capping of the transactions before they are transported to the server.
realtimeve
branch of VisualEditor.The demo is hosted on an Amazon EC2 micro instance, running Ubuntu 11.10. The server uses Node.js v0.8.1 and socket.io v0.9.6. The cluster module used in running the parsoid service forks five workers while running the collaboration server on the master process.
If you’ve got suggestion to improve a feature, or about a new feature or you want to report some bugs, you can get in touch with me directly through my email - ashish[dot]dubey91[at]gmail[dot]com.