Month: September 2011

I’m starting to take some more time away from helping the general MediaWiki 1.18 development and get back to the JavaScript back-end parser experiments that’ll power the initial testing of the visual editor‘s work on existing pages (and, if all goes well, lead to the next-generation core parser).

I’ve made some progress on in-tree template expansion, modeled on parts of PPFrame::expand, Parser::argSubstitution and Parser::braceSubstitution from the current MediaWiki parser.

There are two key differences between this in-progress code and how the stock parser does it:

1.  The stock parser expands a preprocessor node tree as it flattens it into another string (eg for later parsing steps on the compound markup) — the experimental parser produces another node tree.

   Later-stage parsing will deal with re-assembling start and end tokens when producing HTML or other output, but within the tree structure instead of a flat stream of string tokens — that’ll let output know how to mark where pieces of output came from in the input so they can be hooked up to editing activation.

2. Operations like fetching a template from the network are inherently asynchronous in a JavaScript environment, so the iteration loop uses a closure function to ‘suspend’ itself, calling back into the function when the async operation completes.

   Currently this is fairly naive and suspends the entire iterator, meaning that all work gets serialized and every network round-trip will add wait time. A smarter next step could be to keep on iterating over other nodes, then come back to the one that was waiting when it’s ready — this could be a win when working with many templates and high network latency. (Another win can be to pre-fetch things you know you’re going to need in bulk!)

I’m actually a bit intrigued by the idea of more aggressive asynchronous work on the PHP-side code now; while latency is usually low within the data center, things still add up. Working with multiple data centers for failover and load balancing may make it more likely for Wikimedia’s own sites to experience slow data fetches, and things like InstantCommons can already require waiting for potentially slow remote data fetches on third-party sites using shared resources over the internet.

Alas we can’t just take JavaScript-modeled async code and port it straight  to PHP, but PHP does let you do socket i/o and select() and whatnot and could certainly do all sorts of networked requests in background during other CPU operations.

This is still very much in-progress code (and in-progress data structure), but do feel free to take a peek over and give feedback. :)

I fell into some kind of HTML 5 Canvas documentation trance and fell out of it a few hours later with a primitive little game demo, which I hereby dub FlatRoller (source on GitHub):

Gameplay is basically a 2-d side-scroller version of Katamari Damacy, with … not a lot of complexity. Roll your giant ball of stuff left or right and collect stuff to build it up to a larger size! And you can jump. Sometimes you bang into things.

Tested in current releases of Firefox, Chrome, Opera, and Safari, as well as Mobile Safari on iPad. Not tested in Internet Explorer, though IE 9 and 10 should work in theory. Physics are pretty crap, and it doesn’t do wrapping on the play area quite right… and of course it looks like I scrawled the graphics in MS Paint (actually Gimp ;)

But it is kinda fun; I think I’ll clean this up and use it as an example in tutorial documentation for VCS stuff and of course for gfx-heavy web thingies…

Interactive widgets and mini-games/applets using the same sorts of tech are a big potential for online reference and educational media — in particular bringing authoring environments into the wiki or other on-web whatsit should make some really cool projects and learning tools possible.

Update 2011-11-20: Size & multitouch tweaks

We’re in the process of upgrading Wikimedia sites to the about-to-be-released MediaWiki 1.18. So what’s actually new in it?

One of my favorite little improvements is automatic EXIF orientation support for images. Lots of digital cameras and mobile phones handle portrait-mode photographs by saving them as if they were in landscape mode, and marking the file with an orientation tag based on accelerometer data in the device (“oh you were holding the camera sideways? I knew that!”)

Bryan Tong-Minh did most of the work on this a few months ago, and I made a few tweaks recently to make it work a little more consistently. But what does it mean in practice?

Let’s try an example — I took a portrait photo of my coffee mug (mmmm) using my Canon PowerShot and uploaded it to test2.wikipedia.org.

If you load up the raw original image in your browser you’ll find that it looks sideways like this:

Poop! Nobody wants sideways coffee, it’ll just spill all over that shiny laptop.

It used to be that your image would end up looking like this when you uploaded it directly into MediaWiki, but no more!

Now whenever MediaWiki deals with it, it’s automatically rotated to its proper orientation, just like if you loaded it into Gimp or Shotwell (or Photoshop or iPhoto, if you swing that way!)

When this support goes live on Wikimedia Commons, it’ll be a nice help for people uploading camera-original images, as it will no longer be necessary to manually fix the rotation of your photos. (If you’ve edited the photo, _usually_ the rotation gets fixed then.)

Particularly when we look into the near-to-medium future with things like direct photo upload support from mobile devices, and more on-web editing, we can expect to see a lot more camera-original photos going into the system.