Parser 2011/Real-time collaboration/Tasks

Tasks!

Authentication
For the actual submission of the edit, we rely on the current security strategies (edit token, etc.) to assign to a user. Any other users in the session may become part of the comment, but the submitter is responsible for the edit.

However, in the meantime, authentication is necessary to assert to other users in the session that they are editing with such-and-such users.

Also to avoid the possibility of someone "injecting" edits into the concurrent session that are unwanted and not noticed by the editor.

Possibilities:

Become a CentralAuth responder?
In production:
 * Write something in Etherpad which responds to AutoLogin & AutoLogout
 * Will need to access same memcached
 * Configure CentralAuth to call our service as well

Disadvantage: only works in the Wikimedia cluster, not easy to simulate or test. Seems like a bad option for now, although it has the advantage of cancelling a user's access exactly as they log out.

Verification API call
The concurrent etherpad session needs to have
 * A unique identifier for the pad, that other people who want to join will also be able to construct.
 * A method of verifying that a user who wants to join is a registered user of the same wiki that the pad is on, and that they have a certain username.

We will solve this by creating/invoking the etherpad session with five parameters:
 * 1) apiUrl: serves as the unique "wiki identifier", which is simply the api endpoint. (e.g. http://en.wikipedia.org/w/api.php ). We don't use pretty URLs since they are just identified in apache rewrite rules.
 * 2) pageTitle - The page title
 * 3) pageVersion - The page version. Together with pageTitle this uniquely identifies the content we are editing
 * 4) userName - The user name
 * 5) userSessionID - The user session ID

When a user joins or creates a session:

Etherpad verifies the user, by constructing an api url from apiUrl, userName, and userSessionID, e.g.  http://wiki.ivy.local/w/api.php? action=query & list=users & ususers=NeilK & usprop=verifysession & ussessionid=1234567 & format=json

The wiki will return a response with 200 OK and content like:

{"query":{"users":[{"name":"NeilK","verified":"true"}]}}

If the user checks out, it tries to join the pad
 * The pad id is a function of (apiUrl, pageTitle, pageVersion) - could be a hash
 * If the pad doesn't exist, create it!

And, etherpad returns a cookie that authorizes the user to make subsequent Etherpad API requests on that pad. This cookie is a sort of proxy for an edit token, and thus should expire at or before the same moment as the user's edit token does. The cookie should expire when the user closes the page.

etc.

 * Support standard editor as well as WikiEditor
 * Sort of works now, the textarea is #wpTextbox1, and exactly the same, mostly for compatibility?
 * we need to get WikiEditor's collaboration to invoke us after it's modified the HTML around that textarea. Better model? Pubsub with an 'editor ready' event? But how does plain-jane wikimedia know that someone else isn't going to come along?


 * WikiEditor should be hidden properly (still visible at bottom, broken since last time...)


 * theme
 * Variant of nano or micro
 * make pad automatically in monospace mode


 * Toolbar
 * Make API to ACE (the etherpad editor)
 * Same domain JS API, doesn't need postmessage... which is good because we get MOAR browsers
 * Primitives by which it seems we can implement everything we want to duplicate toolbar functionality
 * replace text
 * get selected text
 * get selection position/range
 * set selection relative to document (line number and pos)
 * undo/redo
 * Existing buttons
 * reconceive insertion/editing, need to invoke an object rather than a textarea (or emulate a textarea). Will need to have a single point of entry for the textarea, there are multiple points where #wpTextbox1 is selected.
 * Undo/Redo buttons
 * Add buttons to mediawiki toolbar
 * Invoke the undo/redo functionality in ether-land


 * make gadget js (currently mediawiki-embed.js) non-static, so it can know what its own hostname & port is.


 * Getting the username for the wikimedia cookie (same domain JS)

Step 2a
Collaboration features into new edit surface

Step 2b
Chat (via Wikia's new chat thingy)?