Apache Qpid™ is a high performance open-source message queuing system. But there's no point me telling you all about it - just check it out over at http://qpid.apache.org/.

The Qpid project provides two different message brokers, and several client APIs. However it did not yet have a PHP client API, so I set about writing one :)

Although the PHP binding I created is SWIG-based, it was not as straight-forward as writing a simple SWIG interface file, and compiling... no sir! First off, running SWIG on the standard Qpid headers in PHP mode resulted in SWIG seg-faulting. So after reporting that bug to SWIG (it has since been fixed, yay!) and developing a workaround, I then had to solve a number of small issues, and then write some Qpid Variant ⇔ PHP type-mapping routines.

Now, there are no official binary PIAs for Exchange Server 2000 / 2003. However, Microsoft does provide such PIAs in "source" form (not really source code as such... but we'll get to that) that you can download and compile yourself. There is an MSDN article that explains how to use the Exchange Server PIA wrappers, however I strongly recommend you download the code and read the included "Writing Managed Sinks for SMTP and Transport Events.doc" file instead - it is far more up to date than the MSDN article in areas that are quite significant (such as the actual build process).

Having owned an N900 for a little while now (casting my vote for openness and freedom in the mobile space), I've been eagerly waiting for a MeeGo release that I could install on my N900 and play with. That moment came a little over one week ago! :) So, after waiting for my nice new class-10 microSDHC card to arrive (cheaper to buy online with shipping, than to buy locally), I finally had a play last weekend. I was a little dissapointed :|

Although I had expected a lot of bugs and instabilities, and my overall expectations were quite low at this stage, I was still quite surprised at just how incomplete MeeGo Handset is. I guess my unrealistic expectations stemmed from the fact that the current MeeGo handset release has the version number 1.1 - that implies to me that it should be "fairly complete" (albeit with bugs, etc). However, it is more inline with what I would call a version 0.1.

Now, the back of the Family Pack box says:

Which is completely fine with me, because I always do a fresh install anyway, for performance reasons. So, with all my important data backed up, I formated the disk and proceeded to install.

The initial stages of the installation were pleasantly slick - feeling much more refined than good old XP, but the pleasantries were put on hold when it came time to enter my product key, which was consistently rejected! :(

I've been experimenting with QtSvgDialGauge in a personal project, and so far, I like it a lot! :)

For those who don't know, QtSvgDialGauge is nice SVG-based dial/gauge widget, which is part of the Qt Embedded Widget demos. You can see it (and several other embedded widgets) in action in the Qt Embedded Widgets Catalog and Qt Patient Care Demo applications. And you can download the source for both applications here.

With most non-trivial Qt projects that I create, I like to include a pre-pre-build command in the qmake project file. I'll explain why as we go, but first off, let's look at what I mean by "pre-pre-build" (it is not at all a standard term).

The typical build process (as performed by make looks something like this:

1. For the given target, check if any of the target's dependencies have been updated since it was last (re)built.
   1. If no dependencies have changed, do nothing - we're done ;)
   2. If one or more dependencies have changed, then:
      1. Build each dependent target.
      2. Build this target.
      3. If appropriate, link this target with its dependencies.

That is, of course, a gross oversimplification... but it will do the purpose of this post.

Whoa!! I just got a rather surprising (to me) warning from Gmail. It reads:

You are almost out of space for your Gmail account. You can view our tips on reducing your email storage or purchase additional storage.

As I said, this was a bit of a surprise to me. When I first began using Gmail, I kept a close eye on my storage usage, but it used to climb so slowly that I soon forgot all about it. But upon seeing the above message, I quickly glanced down to read:

You are currently using 6989 MB (95%) of your 7356 MB.

Since Google released Chrome last year, I've gotten used to regularly using two browsers on my PC: Google Chrome for all of my "simple" personal browsing such as webmail, and Firefox for more advanced browsing such as website development. This also tends to create a nice separation of personal (Chrome) versus work (Firefox) tasks.

However, one thing that has bothered me for some time is the (slightly) proprietary nature of Google Chrome... don't get me wrong, Chrome is built from the opensource Chromium project, so it's not all that proprietary, but still, something does not quite sit right with me.

Back in part 1 of this build, I ran in to some overheating concerns with the northbridge. So I decided to try a passive tower cooler for both the north and south bridges.

So here's the new parts that are ready to go... From left to right, they are:

• Thermalright HR-09S (type 3) VRM cooler... which I didn't end up using (more on that later);
• Thermalright HR-05 IFX chipset cooler - this is the straight-up version, which I'll use for the southbridge;
• Thermalright HR-05 SLI IFX chipset cooler - the "bent" version for the northbridge.

According to the Apache URL rewriting guide, the way to handle Canonical Hostnames is like this:

RewriteCond %{HTTP_HOST}   !^fully\.qualified\.domain\.name [NC]
RewriteCond %{HTTP_HOST}   !^$
RewriteRule ^/(.*)         http://fully.qualified.domain.name/$1 [L,R]

Well, those rules are not always sufficient. Specifically, what if you also owned the www.example.com.au domain, and wished to redirect it also to the primary www.example.com domain? The solution is simple - we just need to add a single $ character to the end of the match-pattern of the first RewriteCond like this:

RewriteCond %{HTTP_HOST}   !^fully\.qualified\.domain\.name$ [NC]
RewriteCond %{HTTP_HOST}   !^$
RewriteRule ^/(.*)         http://fully.qualified.domain.name/$1 [L,R]

Now that will work nicely as long as the hosts use standard ports (ie 80 for HTTP, and 443 for HTTPS). However, some Python versions unnecessarily append the standard HTTPS port number to the Host HTTP header. Also I discovered today (after some Apache debug logging) that Adobe AIR applications have the exact same misbehavior for HTTPS, but only when running under Mac OS X.