Skip to content


YME: mandatory upgrade!?

I was treated to this, ridiculously wide, "dialog" just now:


again, no option to cancel, and no brains to realize that I don't have the required privileges, and no option to avoid the 8MB download that won't buy me anything.

I'm just glad that I don't have to quit everything just because some app decides that I have to. On the flip side, it interrupted my listening pleasure, so I'm tetchy.

Maybe this update has fixes for these things... but I'll apply that "mandatory" upgrade when I want to do it.


Scott Kveton of the OSU Open Source Lab (who graciously provide hardware and bandwidth for many open projects, including told me about OSCamp, which seeks to organize the buzz of fringe activity that surrounds OSCON each year.

I know that Rasmus particularly likes to get together with the local community at conferences, something which is often made difficult for them by the high entry prices (any price is high if your ticket isn't being covered by your boss). Last year a bunch of us PHP folks went on down to Portland's PHP User Group to give them a compressed version of the PHP talks at OSCON for free (as in pizza).

OSCamp is intended make these fringe gatherings feel more like part of the conference while still remaining free for anyone to attend. It's still in the early stages of planning/gathering, but I'd say that it's fair bet that "us PHP folks" will be doing something for the local community again this year.

I just sent out an email to the folks I know, so I'll keep you posted.

Ecelerity selected by MessageLabs

MessageLabs have a network consisting of 3,000 servers across 13 data centers on 4 continents and offer very complex policy rules for the mail transiting their system. Such an environment requires a system that is fast, efficient, flexible and manageable.

So we're happy to announce that MessageLabs have selected our MTA product, Ecelerity, to power their global email management system.

As the lead engineer for Ecelerity and architect of a number of the features that MessageLabs are using, I'm particularly proud of our product and the role that it is playing in managing email for so many people (more than 5 million people through MessageLabs alone).

I've previously hinted about this deal; we've known for a while but our marketing folks wanted to time the announcement for best media impact; today is the first day of INBOX 2006 in San Diego, a key industry event.

A lot of hard work has gone into this project on both sides of the atlantic, so this press release is validation that we've all been moving in the right direction. Good job everyone!

YME: still in the dark ages

I'm getting more and more irritated with windows apps that assume that they can do stuff that requires administrative privileges, like automatically install updates.

I don't run as an administrator because I don't want internet facing apps to mangle my system if/when they get hacked. For the past week I've been telling yahoo music engine that I don't want to upgrade now. It should be smart enough to realize that I don't have administrative rights and not prompt me.

Just now, I started to play a track and it gave me no option: it started to download the 8MB update with no way to cancel the operation, then attempted to install it, which failed.

While I'm not especially irritated by "do you want to upgrade now?" dialogs, I am very irritated by something that forces me to waste bandwidth on a download that I can't run. I don't even know where it downloaded the update to, so I might even have to download it again as the administrator. Ah, there it is: it was downloaded to %TEMP% with a temporary filename and a .tmp file extension.

This sucks; yahoo, fix your stuff.

Authentication services

When I designed the back-end for this blog, I built in the capability for understanding multiple authentication sources. It currently supports three different sources: one of which is local and the other two are CVS servers. By supporting remote authentication sources, I spare myself from having to implement a lot of the user management gumph that is needed to support it (email address verification, password management and so on). While this is good for me, if the authentication is perceived as happening on my site, people don't feel quite so comfortable entering their off-site credentials, because they don't really know what I do with their data.

I'm currently going through one of those phases where I'm thinking about what I'd put into "netevil 2.0", and one of those things is adopting support for authenticating against well-known external sites. Ideally, I'd like people to be able to login to Yahoo or Google and then have some way for my blog to determine a subset of their profile data when they post a comment.

This single-sign-on (SSO) concept is nothing new; Microsoft's passport has been around for quite some time now, and there are newer open specifications being designed by SXIP and the Libery Alliance. Both of these projects are working on IETF draft standards for identity management and federation protocols to facilitate SSO. SXIP is very open and has an implementation in PHP that you can download and use. Liberty feels somewhat closed, and has no reference implementation in any scripting language, which immediately creates quite a high barrier to entry for a large portion of the web developer population.

So, we have one established SSO provider (MS passport) and two entities developing SSO technology. Why haven't I seen any sites, aside from passport enabled sites, using anything like this stuff? I think part of the problem is that SXIP and Liberty are providing the technology but not providing the actual authentication services. Taking SXIP as an example, if I want to SXIP enable my site I need to direct users to a SXIP homesite where they can create an identity, and which can then authenticate them with my blog. The problem is that there aren't really any SXIP homesites out there, so I'd need to implement one myself, and we're back at square one.

I think it would be a huge thing if the big guys (yahoo, google) could implement something like SXIP and allow third-party applications to authenticate users against them. Yahoo is almost there already--if you look at the Flickr API you'll see that you can have flickr authenticate users and provide your application with an authentication token (subject to approval from the user). From that token you can obtain the name of the user, and use that to render the name of the person submitting comments to your site.

It'll be interesting to see what, if any, developments are made in this area.

Extending PHP

While poking around the disks in my linux box, I found my materials for a session on extending PHP that I originally gave as a 3 hour tutorial at PHP{Con West 2003.

Sadly, I seem to have lost the working C code (libares bindings for PHP), but all the relevant parts can be found in the comprehensive PDF I made from the slides: Extending PHP Slides (PDF). The content is based on PHP 4, but should still be applicable to PHP 5.

As it happens, Mike Wallner has recently built his own PECL extension for libares, which is much more complete (and complex) than my examples.

Programming PHP

The second edition of Programming PHP was recently published. The O'Reilly press release said:

Rasmus Lerdorf and Kevin Tatroe provided the guidelines for this book. The newest author is Peter MacIntyre, a Zend Certified Engineer with more than five years experience in PHP. Wez Furlong and Chris Shiflett also contributed. Furlong modernized the "Extending PHP" chapter, and Shiflett brought his renowned expertise in updating the "Security" chapter.

Implementing PDO drivers... using PHP

An interesting development that sprang from a conversation I had with Sara Golemon at the Zend Conference last year: user-space PDO drivers. If you don't know what I'm talking about, it's the ability to be able to define classes in PHP that implement PDO drivers.

It'll be interesting to see what people make of this. I was chatting about it with Chris last night, and he suggested that it might serve as a useful bridge for systems that have no native library connectivity. PDO::User could be used to shoe-horn in connectivity without having to radically rewrite other application code. Another similar idea is to map older database extensions as PDO drivers.

It's still early days yet, but it will be interesting to see where this goes. Thanks Sara :)

Just the facts, ma'am

It looks like this PHP vs ASP.NET article really struck a nerve with Joe Stagner.

Joe's response is perhaps a little pro-Microsoft (you can't really blame him for that--he does work there :-) but the essence of his response rings true; there's nowhere near enough factual data in the OTN article to make a balanced decision one way or the other.

To be fair to Sean (the author of the OTN article), it does say "Opinion" across the top of the page and the byline is "One developer's view of the pros and cons of the two most popular means of building web applications", but it's easy to forget those once you're into the article.

I don't want to get caught up in a comparison myself so I will say that a good systems architect will take into account a wide range of factors before arriving at a decision about what is the right combination of tools for the job, and that Joe's response reminds us that projects for really big customers tend to have different non-technical criteria to what I'm going to call the "typical" PHP customer. By non-technical criteria I mean things like business or political concerns--things like corporate mandates for technology choice, considerations based on the skill-set of a possibly very large existing IT staff and so on.

In plain english, it may cost next to nothing to employ PHP developers to build an application, but it may cost a small fortune to "re-tool" the support infrastructure to be able to effectively deploy that application in an exclusively Microsoft/Windows environment. In this situation PHP is not the better solution, even if it would have gotten the job done in less time and with fewer lines of code.

The point of this blog entry is to encourage people to think a bit harder before they sit down to write. You should try to qualify your observations by talking about the environment and other circumstances that apply to situation and then back it up with some factual data. This will turn anecdotal stories into a useful technical resource.