Jun 15

…and about time too! I’ve posted before about brinkster’s inability on IIS to support ‘pretty’ permalinks, and given the many issues with upgrading prior versions of WordPress on Brinkster, mostly resulting in a switch to the linux platform, had put me off attempting such foolhardy excesses. But I just happened to check today and they appeared to support the latest build (version 2.8) of WordPress (as I’m sure they have for some time, I just never noticed). So despite  the many dire warnings and consequences of old, I did it and it was a doddle (following the manual upgrade instructions). Then simply clicking the appropriate option in the Permalink settings, it all seems to work. Whether this was the result of Wordpress or Brinkster I don’t know (though given the latter’s prior intransigence on this issue, I’d prefer to think it was the former), but I’m glad for it all the same…

My point? Well, apart from the aesthetic and more human readable characteristics of a post that ends “/robbie/why-x-sucks” rather than “/robbie/?p=n”; a decent google rank clearer prefers this. That said, I’ve had a thing about ‘permalinks’ for quite some time. Ever since I wrote my first config utility that had to be reused in multiple applications and environments (using DNS resolution), but especially years ago on an internet web content management system (where I had to justify at a ’business’ meeting why we were using our own ’internal’ guid as a primary resolver). At that time there was no little debate about ‘permanent’ or ‘pesistent’ urls or purls, as they were commonly called. Both config utils and links on websites need to relate to resources with specific identities, but it’s the job of URLs to locate those, and URLs change – even if the identity of the resource doesn’t. For example when I upgraded my blog, all my post’s URLs changed. But their permalinks don’t. WordPress uses its own internal locator, so either http://www.wellitworkedlasttime.com/robbie/?p=38 or the new style http://www.wellitworkedlasttime.com/robbie/index.php/2008/wordpress-pretty-permalinks/ is equally valid. And frankly that doesn’t matter – all external cached links on google, twitter  or wherever, will be resolved providing the application is running, and that’s the point. If it’s not, the resource should be unavailable.

The idea that persistent URLs ought to exist somewhere out on ‘the cloud’ is simply wrong. I was about to add this link to purl.org, most known for its use in dublin core metatags perhaps, when I saw this:

“We have reverted back to the old purl server. Any PURLS, USERID, GROUPS, and DOMAINS that were added after 5:50 am edt on 04/07/09 have been lost. We will try to recover them, but we are not sure it is possible at this time.”

An amusing aside (yeah, persistent, my ass!), but my real issue is this from Wikipedia:

“PURLs are an interim measure — while Uniform Resource Names(URNs) are being mainstreamed — to solve the problem of transitory URIs in location-based URI schemes like HTTP. Persistence problems are caused by the practical impossibility of every user having their own domain name, and the inconvenience and money involved in re-registering domain names, that results in WWW authors putting their documents in rather arbitrary locations of questionable persistence (i.e. wherever they can get the WWW space). Existing official PURLs (on Purl.Org) will probably be mapped to a URN namespace at a later date.”

Interim? Impossible? Inconvenient? Expensive? Oh Really? A pretty lame case if ever there was one… In my view the location of a resource is best resolved at the edge, close to the resource itself, by software under the owner’s control. It’s really not that much bother…

preload preload preload