User:Dash1291/GSoC 2012 Application

Identity
Name: Ashish Dubey Email: ashish.dubey91@gmail.com Project title: Realtime collaboration on Visual Editor

Contact/working info
Timezone: UTC+5.5(India) Typical working hours: 11 am to 2 am until July, 5 pm to 2 am after July. IRC or IM networks/handle(s): ashish_d

Project summary
Realtime collaboration on Visual Editor would allow Visual Editor to be used much like Etherpad, Google Wave, and similar other collaborative editors. As of now, the realtime collaboration project is to be implemented in two phases.

Phase 1
This phase features one client as an editor in an editing session and other clients connected to that editing session would only see the changes made to the page by the editor. Editing sessions could be passed to other clients for them to edit. Once prototyped, this would be much like a 'read-only' collaborative editing tool for the clients connected to an editing session except for one client who can write to the editing session and will provide an initial codebase for Phase 2 to be implemented on.

Phase 2
With initial codebase done in Phase 1, this would add the provision of editing by multiple clients connected to the same editing session. Everyone can edit while seeing changes done by others. This would have to incorporate much complicated client and incoming transactions handling. Measures to consolidate concurrent transactions must also be implemented. Hence, this phase targets a complete realtime collaborative editor like Etherpad or Google Wave.

This project aims at implementing Phase 1 of the Realtime Collaboration project which would include -


 * 1) Collaboration server to serve editing sessions to new clients, and changes to the connected clients.
 * 2) Client module(s) for communicating with the collaboration server.

Scope of Work

 * 1) Collaboration server implemented in Node.js.
 * 2) * Use parser to convert wikitext into a DOM for document transport and linear model to store the server's document state.
 * 3) * Integration of VE modules to handle the document model and apply incoming transactions to the document model.
 * 4) * Implement Socket.IO API for client/server communication.
 * 5) Client adapter which hooks into the editing surface for translating local document changes to the server.
 * 6) * Initiate and maintain the editing session with the collaboration server.
 * 7) * Respond to the incoming transactions from the server by applying them to the local document.
 * 8) * Bind its funtionality against the server's Socker.IO API.

About you
I am Ashish Dubey, a B.Tech, Computer Science Engineering student, in JIIT, Noida, India. I'm mostly interested in web development and networking using PHP, JavaScript, and Python. I love doing mashups, back-end development, scripts that make life easy and working with moving parts while developing. I've used Etherpad while collaborating on projects online, and realized how awesome would it be to use Etherpad like functionality to edit a wiki page, and that is what has motivated me to work on this project.

Required deliverables

 * Node.js based collaboration server.
 * Features single editor in an editing session, others connected to a session can spectate changes live.
 * Gracefully support extending with Phase 2 features like conflict resolution/Operational Transformation.
 * Tracked list of module dependencies.
 * Client adapter pluggable into the Visual Editor's transaction system that binds against the server's API.

If time permits

 * Phase 2 features; Multiple editors in an editing session with concurrency control.

Project schedule

 * Community bonding period: study modular structure and coding style of Visual Editor in more detail, laying down modular design of the project
 * 3-4 weeks: Node based collaboration server
 * 3 weeks: Client adapter

Milestone 1: Working integrated prototype


 * 2 weeks: Add unit tests.
 * 1 week: Ensuring proper integration with Visual Editor demos and sandbox.
 * 2 weeks: Testing and documentation.

The above plan could go as expected or invariably re-distribute among the tasks, but a positive margin of time left would be great for starting Phase 2 work.

Participation
I believe IRC is the best place to ask for help, and that's why I'm logged into #mediawiki while I'm working. In specific cases, when I don't find the particular person concerned with my question, then I tend to use email. For subjects, that I expect a good amount of feedback, I opt for the mailing lists. I will use a local environment for running MediaWiki and Node server for development. And also, periodically, I'll deploy to a cloud instance so that demonstrations are possible and good looking. Git migration should be complete by the time I start working, so I'll commit early and often to my branch.

Past open source experience
I'm an active member of Open Source Developer's Club in my college. Everything I develop, large or small, is open source and whatever I use to develop is open source. Among the very good open source things I've worked with while development and loved are, MediaWiki, WordPress, Django, Node.js and Twisted. As for the contributions, I've also attended a few open source meetups including PyCon India 2011, Wikipedia Hackathon in Pune 2012 and few local meetups about Drupal, Firefox, etc.
 * Commiter to MediaWiki, developed an extension and contributed a patch to the visual editor project.
 * I've contributed to the Mozilla's AMO project with two addons in their addons respository and also contributed a few patches to their website's infrastructure that is based on Django.
 * Contributed a plugin to WordPress plugin repository.

Any other info
Visual Editor is built in a way that it would gracefully support building realtime collaboration over it. The transitions that it is going through now, would take it even nearer. I've done some work on a little collaboration server and a client adapter which work by naively communicating transactions among the clients editing a document. All that work lives in my GitHub respository.

Apart from that, I've also read considerably on concurrency control measures because earlier my aim was to implement the full fledged realtime collaboration without splitting them into two phases but that didn't fit into the scope right. So, I would try to finish Phase 1 work as soon as possible so that I can leave as much time possible to start working on Phase 2. But even, if that doesn't fit in time, Phase 2 will be high in my TODO list after GSoC is over.