Context in MidCOM is an object that contains all useful information related to the request at hand: arguments, URL, templating information. And the plan is to make it much more.

Context is the main way for controllers to find out about their environment, and for the templating system to decide which views to run and how. As we want to make the new MidCOM lean and efficient, we did not want to stick everything possible into the context. But in order to solve problems developers will need more stuff there. And so the idea of context injectors was born.

Context injectors are a new API components can use to add or modify information in the current context. The injectors will be run in two places:

• Process injectors will be called before dispatcher loads the component and calls the controller
• Template injectors will be called after controller has finished and before a template is collected and displayed

There are many things you can do there. Some immediate use cases are:

• Geopositioning injector could add user's current location to the context so that a controller can fetch nearby data
• Theming injector could switch the template entry point (in old Midgard term's the ROOT element) according to user's wishes
• Mobile optimization injector could also switch the template entry point if user is accessing the site with an iPhone or OpenMoko

Using context injectors

The way this works is relatively simple. To create an injector, you create a component and create an injector class to it. Depending which injector you want to provide, you either implement a inject_process or inject_template public method there. The method will have full access to the current context (in $_MIDCOM->context) and can add or change things there. The just declare that you have the class in the component's manifest by adding a key process_injector or template_injector with value being the class name.

MidCOM will take care of loading the component in question in the right time, and of calling the injector method. This will all happen automatically once the component is installed.

If your controller or template uses context information that is not part of the default context data, then make sure to first check that the data is available via an isset(). This way your component will be able to work around missing context information if applicable to your scenario, or throw an error.

Written outside in the Platonik waterpipe cafe in Beşiktaş, Istanbul, while vine leaves above keep the air cool enough for working. The picture is from the Freds House blog.

Having read Neal Stephenson's Snow Crash where the lead character Hiro, a fellow swordfighter and free hacker is making his living by collecting intel to upload onto the CIC library, the concept had some appeal. To test it, I created some pages:

Workstreaming
Workstreaming means collecting activities of geographically dispersed team members into a consistent news feed, enabling managers to track process and colleagues to stay up-to-date with the day-by-day happenings.

Developing P2P business applications
Moving business applications to the web has solved many issues like easier deployment and backups, but at same time introduced a single point of failure in the infrastructure. A group of open source frameworks seeks to solve the issue by helping developers to migrate their applications into resilient and scalable peer-to-peer networks.

Haedong Kumdo
Haedong Kumdo is a modern martial art based on ancient Korean sword techniques.

This should not detract from my open content activities, as the Knol pages are also Creative Commons-licensed.

Just like we should aspire to use renewable energy sources to help the health of the planet, we should also use reusable software elements to create robust, healthy code for our customers. Eco-friendly practices might be thought of as applicable to software devlopment. Just as we are concerned with the various biota and climate of the planet, we should be concerned with the over-all health of the software eco-system.

How does Midgard sit in with these ideas? Well, the current version of it does not. MidCOM 2 is a heavy, enterprise-oriented CMS framework that requires big machines, or even clusters to run.

But things are quite different in Midgard 2 land. We have rewritten the MidCOM framework from scratch, removing the need to have abstractions on top of abstractions to support the shift from classic Midgard APIs to the new ones, and from PHP4 to more object-oriented PHP versions. We have also focused on simplicity and adaptability, to make MidCOM an easier environment to work with for site developers.

While MidCOM3 is not due to be out before next March, Tero Heikkinen, an early adopter has been building some production sites with it already. And his experiences state that not only the performance is much better, but also it requires much less work from programmers.

I know Rasmus' argument is that frameworks are evil by requiring developers to adopt to their own concepts, and by introducing unnecessary overhead. But we should look beyond mere server-level productivity, and take programmer productivity into account. A framework makes things much easier for agile teams, enabling people with different competences to work in their isolated environments. Programmers can work on the code, and designers on the templates for instance.

While this makes the actual development and deployment process more efficient, how much performance is lost due to the framework?

Lies, damn lies and benchmarks

Like Rasmus, I used an APC-cached simple PHP "hello world" file as the baseline for my benchmarks. On my dog slow MacBook Air, the simple PHP file was able to serve 32.91 requests per second.

MidCOM3, when run on Midgard 8.09 with APC and memcached was able to serve 8.90 request per second, or in other words performed at 27% of the plain PHP file. Not too good, but considered that much SQL is run to serve a Midgard page, there are good explanations at this.

But compared to Drupal, which I did not install but instead calculated the performance based on the difference between my baseline (32.91 r/s) and Rasmus' (611.78 r/s), MidCOM3 was doing quite fine. Drupal would only be serving about 2.5 requests per second on my box. Zend Framework, again calculated from Rasmus' data would provide 6.5 request per second.

And this is not all. Piotr Pokora has done a stellar work with Midgard2, which will come out in spring numbered 9.03. With it, MidCOM's numbers were quite a lot better: 25.37 requests per second, or 77% of the simple PHP file's performance. This is actually faster than the same simple PHP file on my box without APC (24.84 r/s).

I believe the MidCOM3 performance story does not end here. Piotras has been doing experiments with caching Midgard's initial request data to reduce database queries, and MidCOM3 still misses the extensive caching infrastructure provided by MidCOM2. When these are in place, we may get pretty damn close to the plain PHP numbers.

So, with these numbers, I think we can say that Midgard2 will be quite a good framework for doing green programming while still retaining agile team efficiency.

Towards a greener future

This matters quite a lot, as then Midgard can be run with much smaller virtual machines consuming much less electricity to serve interesting information-rich applications.

When Ragnaroek gets out in end of September we will start focusing our efforts to the new platform that already is showing so much promise. A brighter, greener, more efficient future lies ahead!

There is a project in works by me to rewrite Midgard’s core engine from plain C to Vala. Midgard 8.09’s code is taking huge use of GObject infrastructure and Vala is so good in expressing GObjects that actual development is much much easier.

It is not surprising that the project itself will be code-named ‘Váli’. It will include both streamlining of Midgard core and use of SpiderMonkey java script language embedded engine (courtesy of Mozilla project) to allow server-side extension of the core. Some might see these changes as an attempt to bring more web developers to Midgard’s Core but as this will anyway happen after Ragnaroek, I think its pure target is to simplify work for remaining gods on a new world for mere humans.

I think the Midgard Gathering in November shall be quite memorable, and not only because of the quantities of Polish vodka and sauna that will be present...

A thousand years ago, men from my lands traveled here in search of opportunities and adventure. Now, due to intercontinental relationships and working permits, I follow their footsteps.

While Istanbul didn't score perfectly in Monocle's Quality of Life index, I still find it a quite appealing place for a web worker. The lifestyle is more relaxed than in the north, WiFi-equipped cafes are everywhere, food is good, and the old city and Bosporus are absolutely beautiful.

Web working while running a consultancy in Helsinki is not the easiest thing to do, but with some new processes, and new tools I think we may be able to cope. The main thing is to learn using telepresence tools better than we do now.

At least the web working test run I did in London earlier this month felt very productive. Now the plan is to split my time between Helsinki and Istanbul, and of course the mandatory conference trips. This all will be challenging for regular project work, and so good web working tips will be appreciated!

But in any case, my reasons for being in Istanbul go far beyond mere working environment and productivity...

Here are some notes from the conference:

• PHP 5.3 is going to have alpha2 next week. Namespaces could be nice in MidCOM, but I wonder how well they will work with the autoloader
• Turtle is a "friend-to-friend" framework to provide secure P2P data sharing in a trust network. Could be interesting with Midgard replication
• Apache and Lighttpd support the X-Sendfile header which we could utilize for simpler, fast file serving with Midgard
• The MINIX idea of automatically reincarnated user-space drivers and servers is pretty cool
• Lots of OpenMoko FreeRunner phones here!

Some interesting talks still left, including:

• Apache Mahout machine learning system
• dropr message queue for PHP
• Using PEAR installer for website releases

Unfortunately the Atom Publishing Protocol talk is only in German...

Midgard's positioning framework has been Fire Eagle compatible since March this year. Now that the service is open for a wider audience, I though it would be useful to tell how to activate it with your Midgard-powered site.

You need to authorize Midgard with your Fire Eagle account. To do this, go to:

http://www.example.net/midcom-exec-org.routamc.positioning/test-fireeagle.php

and follow the authorization instructions. This is due to Fire Eagle using the nice OAuth protocol.

Once this is done MidCOM cron will start tracking your Fire Eagle location. All objects you have created (photos, blogs, comments, etc) will then be automatically tagged with where you made them.

In addition to making normal requests to the various routes available, routes provided by other folders can be loaded dynamically anywhere on the site. This is useful for instance for loading five latest news items to front page.

To make life easier, I now added a new feature to midcom.admin.help, the online help component. Each folder will automatically list their documentation and available routes when you access their URL __ais/help:

To get this feature you only need to upgrade the help component:

# pear upgrade midcom/midcom_admin_help

http://jaiku.com/channel/Nemein

If you are a Jaiku user, feel free to join the channel. Others can follow it via the RSS feed.

With feature branches the idea is that each feature or bug fix is being developed in its own branch, and only landed to trunk (master in git terminology) when ready. This keeps the trunk clean and easy to test.

While the SVN migration will only happen in next developer meeting, you can already start using git for Midgard development thanks to git-svn. Once you have a working checkout, here is how you work with feature branches:

Ensure you have the latest stuff:

git svn rebase

Create a new branch:

git branch mynewfeature

Go to the new branch:

git checkout mynewfeature

Hack, add files, commit, test

Ensure the diff looks correct:

git diff master..HEAD

Go back to master:

git checkout master

Merge your feature branch:

git merge mynewfeature

Commit to SVN:

git svn dcommit

If you want to also work with other Midgard or MidCOM versions from SVN, check out the how to track multiple svn branches in git tutorial.