User:NeilK/Worklog/2011-03-07 to 2011-03-14

March 14

Reviewed some of the bugs Kaldari says he fixed, there are some errors in the fixes, reassigning / reopening

Talked with mdale about configuration of UploadWizard (needs to be PHP-oriented. We need to do this anyway so licenses are configurable. Adding bug -- always knew I had to do this but was procrastinating on making a bug for it)

Investigating IE issues which I thought were there but suddenly aren't? With IE messages disappearing? But now it seems to be jquery's fault and not the message library?

2pm-3:30pm meeting with another Etherpad/Wave person (Danilatos) to pick their brains on Rich Text Editing, Operational transforms. Some important things to remember:

• the "abstract" format should work well with OT. Wave devised a scheme whereby the text was contained in simple blocks, delimited by "line" elements. A line could be an ordinary paragraph, a bullet point, a heading. Any other markup was taken care of with annotation overlays. Off to the side there was a data structure which kept track of the offsets where certain things like boldness, italicness, etc. begin and end. Even links. These can intersect. Offset calculation was fast since offsets were calculated in an red-black tree. The point here is that Wave didn't have to split nodes or create new nodes just because someone pressed return, or started a bold block. Instead they just insert a new line node, or, at most, rejigger the offsets of their annotation overlays. Not only is it simpler it's a lot closer to how normal humans think about text anyway.
• To support an OT editor, and remain even vaguely in the MediaWiki model, we need servers to manage editing sessions which other people can join.
  • In front, a set of servers to route OT transactions to servers which will have affinity with articles (via consistent hashing or whatever). Java seems like the only plausible way to run those servers (esp. if we want to run Wave code), which adds to ops burden. Alolita notes that Java is far more resource hungry than PHP on a per-user basis, although IMO this service sounds simple enough.
• More of Wave is due to be open sourced, so there will be more of a community and more for us to use should we want to adapt it.

Thoughts: our mandate is for an RTE editor, but Trevor & I would really like an OT-style editor. Would radically change community interaction, probably for the better. Possibly we could do RTE first, but keep the door open for OT -- have the feature in reserve, keep it alive with some basic tests but don't worry about going live, and then really give'er by 2012.

Reviewed some of mdale's changes to UploadWizard. He wants to contort it to support Firefogg again, so he did a lot of cleanup which I was procrastinating on. First time I have ever marked code "ok" in MediaWiki, although it's to code where I'm the primary author. Let's see what happens.

Tried to tackle a very hard IE bug (which i deferred until I had language sorted out) but somehow the transition to RL and jQuery 1.4 seems to have made it go away all by itself. Kind of depressing since this was part of my motivation for getting language right.

Tried to help Kaldari with some perplexing issues he was facing with his config... it was like everything was melting down

Dicked around with eliminating various parts of UploadWizard which are now redundant. Didn't pull the trigger on moving my mw.log.js to replace the main one.

Deployed code to commons.prototype, fixed up all the bitrot that has occurred there since we last deployed. Also found that the new JavaScriptMinifier library had a subtle but hilarious incompatibility with the PHP version we run in production. (It removed all "f"s and "v"s. Fixed). In principle we can now get community banging on this again.