Jeroens blog

I’ve been working on Maps and Semantic Maps 0.6, the next big, awesome, release of both MediaWiki extensions, for over a month now. I also released an early alpha on the 3th of April. All planned new features have been implemented, and known bugs from 0.5.x have been fixed. So you might wonder why 0.6 is still not out.

In response to the possibility of someone doing work on Maps and Semantic Maps during the upcoming Google Summer of Code, I took a critical look at the current structure, holding into account all the things I learned over the last two month while working on Storyboard. I came to the conclusion that a bunch of things ought to be handled in a cleaner fashion, and started to refactor this code. The most difficult part here is changing how the display_map and display_point(s) parser functions handle their mapping service parameter and validate the provided location(s). I’ve been wanting to change this since 0.4, but didn’t since it’s rather tricky to do. I decided to finally get this done now, and have done most of the work. To complete these changes, I’ll have to make some rather complex modifications to Validator, which can take a while to complete. That’s the last thing that needs to be done before the 0.6 release though

I estimate this should be done in approximately 2 weeks, maybe sooner. After that I’m planning to release at least one RC, to ensure stability and complete awesomeness, cause really a lot has been changed. I figure about three quarters of the codebase has been changed in one way or another!

After this release a lot of cool new features can be added, which I might do before the GSoC coding period starts. There are also a few people who wanted to do a mapping project for GSoC at the WMF, but did not get accepted, which are planning to do some effort here after all, which is totally awesome

Like last year, I’ve been accepted for GSoC 2010 – yay!

The Google Summer of Code (GSoC) is an annual program, first held from May to August 2005, in which Google awards stipends to hundreds of students who successfully complete a requested free software / open-source coding project during the summer.

My project is creating an awesome extension management platform for MediaWiki, facilitating the installation, updating, removal and configuration of extensions. I’ll get mentored by Brion Vibber, which is probably the best known MediaWiki developer there is. The underneath paragraphs are out-takes of my actual proposal.

Project summary

The goal of this project is to create an administration panel from where wiki administrators can update, install and remove extensions. A second goal would be to allow management of the installed extensions.

A panel where wiki administrators can install, update and remove extensions would have huge benefits. First of all, people would not have to manually download an extension and put an includes in LocalSettings, neither would they need to worry about compatibility and dependencies. Hitting an update button also takes considerably less time then doing the whole download routine again, and will cause people to run more up to date extensions. Another important advantage is that people will get extensions recommended, and can easily browse them. This way people will find extensions that do something they wanted but did not know about, and in general have extensions that better suit their needs. A third advantage is that extension developers won’t need to do extreme efforts to let people know there is a new version (and probably still only reach part of the relevant public). This is inspired on the way Word-press does things.

The second goal of this project is to add setting management for individual extensions. Currently extension settings are managed via LocalSettings. The aim here is to completely remove the need of editing any file directly by storing the configuration the the MediaWiki database, and creating a GUI to modify these settings. This would involve creating API modules so extensions can add and update their own settings. Work on this will only be started after the first goal is completed, and is seen as an “if time permits to-do”.

A third, also optional, goal would be to create a management interface for the wiki’s configuration itself. This is very similar to the second goal, and should be kept in mind while creating the management for extension settings. I do not expect to complete this to-do during GSoC, but want to provide the foundations for it, so this can be completed after the project itself is finished.

Deliverables

Note: the beneath list is a guideline only.

Things the administration panel should be capable of:

Required deliverables

• Automatic checking for extension updates (and updates to MW itself)

• Download and install option for extension updates

• Download and install option for extensions that have not yet been installed

• Removal of installed extensions

• Dependency and compatibility checking (both for installation, removal and updating)

• Extension browsing
  • Recommendation of similar extensions
  • Showing a list of most used and most recommended extensions
  • Finding extensions by category or keywords

• Enabling and disabling of installed extensions (so without removing them)

If time permits

• Management of settings specific to each extension.

• Management of MediaWiki configuration.

Project schedule

I’m for a loose schedule, since I believe this is the most efficient. I have no doubt that the to-do list will change a lot during the project, items will be changed, moved, multiple new ones will be added, and some might be removed. A fixes schedule would take away flexibility and stand in the way of efficiency. One of the main reasons to have a schedule is to ensure the student does not take the project to lightly, end ends up making insufficient progress. I like to believe I have clearly demonstrated that I will put considerable effort in such projects, even without any schedule, during last yeas GSoC, and with all the commits I’ve made since then.

This list contains some loose planning without any dates:

• Discuss the best way to structure the platform with mentor, and other relevant people.

• Investigate how similar functionality works with other software, and which aspects of these implementations can be used.

• Get the requited knowledge of MW to be able to create the platform in an efficient and modular fashion.

• Create the panel with the most basic features, then release and document it.

• Add the other features, possibly spread over several releases.

• (Start on the extension setting management functionality.)

• (Start on the MediaWiki configuration management functionality.)

• (Add other awesome things to the platform.)

• Take over the worlds and make everyone use this platform.

My current planning

I have to finish up the work I’m currently doing for the Wikimedia Foundation before I can fully start on this, and also like to release Maps and Semantic Maps 0.6 before then. This will probably be in two to tree weeks from now.

Also see the Wikimedia tech blog post which links to the other accepted projects.

With my last commit I made yesterday, I entered the top 25 all time MediaWiki contributors. The below screenshot from Ohloh shows and my current commit count

I estimate It’ll take me just over 2 months to enter the top 20, as I’m currently committing roughly 150 changes a month.

During the past two weeks I’ve been putting some effort in making some big changes to the source of Maps and Semantic Maps, and adding some awesome new features. Although not every to-do for the 0.6 release has been completed, I’ve made an early alpha version available which allows you to try out some of the exiting new functionality. So let’s have a look at the most notable changes since 0.5.5.

New features

• Support for various width and height notations. Previously Maps only accepted width and height values is px, forcing you to use maps of fixed sizes. Since most people want to have their complete page width visible even on small screens, this resulted in a lot of people using rather small maps, and so wasting screen space. 0.6 allows you to specify the size in px, ex, em, and most importantly, in %. The syntax is what you’d expect: width=”420px”, width=”420em”, width=”42%”. width=”420″ will default to using px, so is backward compatible. When using the % values, maps will even adapt their size when the screen width or the height of the container they are in is changed after the page has loaded See my wiki for some cool examples. Although this is really basic functionality in a way, it’s awesome to finally have it available.
• Added full support for DMS, DD, DM and float coordinate notations, both their directional and non-directional variants. This means you can now enter coordinates in these notations in the display_point(s) and display_map parser functions, as well as make Semantic Maps recognize them as geographical coordinates. Smart geocoding support has also been added to #geocode, meaning you can now pass along coordinates as well as addresses, so you don’t have to double check if your passing along an address to prevent losing the value.
• Coordinate formatting support. Along with the smart geocoding support, #geocode now also accepts 2 parameters to specify the output notation. Since you can pass along coordinates, this means you can change the notation of a set of coordinates using #geocode. A new parser function, #coordinates, has been added specifically for this purpose, so for pure formatting, you should use this one rather then #geocode. Both parser functions work with a hybrid parameter system that supports several ‘default’ parameter (ones that consist of only a value, and no name) and named parameters. You can work with names or without for the default ones, and the default ones in #geocode are the same as the old parameter order, so backward compatibility is retained.
• Rewrote map html and js output. This is now done in a cleaner, safer and more consistent way, for all mapping services in both Maps and Semantic Maps. This is not a new feature, but such a big refactoring it’s worth noting.

More to come…

• Native support for geographical proximity queries in Semantic Maps. This will require quite some work to do in a clean and efficient way, so will probably one of the last features finished for 0.6.
• OpenLayers 2.9 support. Since Maps 0.1, it has been supporting OpenLayers 2.8, and 2.9 is just about to be released, so It’ll be nice to see the progress made there.

On top of these changes to the extensions, I’m drastically redoing the documentation and examples. I’ll post more about that later on though

I’ve been thinking about switching to GMail for a long while now, but didn’t do this since there apparently was no way to forward emails from yahoo! mail to GMail without paying for it. I got so annoyed today though, I did some Google searching, and found a rather hacky, but working, solution.

Since I won’t use my Yahoo! address any more now, I’m also importing all my emails to GMail. Considering I have over 28k (which is over 3x >9000!), staring in may 2004, this is going to take a while though

I created 2 brand new Ohloh projects for Maps and Semantic Maps. This is really cool since I can now analyse my own commit behaviour for those extensions better, as well as see contributions by other people in a more graphical way. It’s also sort of a win that I got the project named ‘maps’ there. Now time for some eye candy widgets of these 2 projects

References

• Maps Ohloh project
• Semantic Maps Ohloh project

This diff, which I seriously made without realizing how epic it was at first, is definitely worth a blog post.