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(IST - 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
MediaWiki.org User: Dash1291

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 realtime collaborative editing is to be implemented in two phases. (See Visual_editor/Realtime_collaboration)

This project aims at implementing Phase 1 of the Realtime Collaboration project whose features would be -

Allow single editor in an editing session, others can spectate changes made in realtime.
The editing control can be passed over to another client by the current editor.
Provide codebase for extending with Phase 2 features; Multiple editors, and concurrency control.

Scope of Work

Collaboration server implemented in Node.js.
- Use parser to convert wikitext into a DOM for document transport and linear model to store the server's document state.
- Integration of VE modules to handle the document model and apply incoming transactions to the document model. This would involve reusing the Visual Editor's data model and transaction processing modules on the server side.
- Implement Socket.IO API for client/server communication.
Client adapter which hooks into the editing surface for translating local document changes to the server.
- Initiate and maintain the editing session with the collaboration server.
- Respond to the incoming transactions from the server by applying them to the local document.
- Bind its functionality against the server's Socket.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.

Deliverables

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.
- Lay down modular design of the project.
- Achieve the above by working with the mentor(s) and other community people interested in the project.

3-4 weeks: Node based collaboration server.
- Parser integration.
- Visual Editor's data model synthesis.
- Socket.IO API for client/server interaction.

Milestone 1: Prototype of the collaboration server; Ready to serve the document and communicate changes.

3 weeks: Client adapter.
- Integration into Visual Editor's transaction system.
- Bind against server's Socket.IO API.

Milestone 2: Working integrated prototype; Ready for integrated testing.

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 Developers 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,

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.
All my other projects can be found on my GitHub profile.

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.

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. Perhaps, have deployed a demo out of it. See User:Dash1291/GSoC_Demo.

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.