the corner office

No more excuses, time to get back to the much-neglected new blog template. This post is just a few thoughts on defining URL structure.

My current blog has links of the form http://www.thecorneroffice.org/060225-0915. That's a nice and clean URL, but there are two things I plan to change. First, not all blog content is behind the plink directory, so the blog effectively sits in the 'root' context. This is fine for a domain name that's blog-centric and little else, but one of the things I liked about 'thecorneroffice.org' as a generic host name was that I could hang other sites (user directories, etc) off of it down the line. So the first change I'm keen to implement is that the new blog will be sitting in its own context, something like www.thecorneroffice.org/blog/ze-plink.

Since that breaks incoming links already, I can tackle the next pet niggle. I don't like the fact that my permalinks don't have a file extension. It's not strictly necessary, but I think it's good netiquette. What extension will I use? They'll have .html extensions. A principle I'm quite partial to is that bookmarkable (ie. long-lived) links should hide implementation details. Mypage.php is going to break if you move away from PHP. Ditto for jsp's and asp's and nsf's and whatnot. I'm not sure if the web powers that be would frown upon it, but my feeling is that if a page is serving up HTML, then giving it a .html extension is not a bad thing, irrespective of what's actually generating it.

Apart from being able to switch web app engines without breaking URLs, it also means that you can dump the entire site to HTML one day and serve it statically, if you want to. That's another reason why I'm not fond of index.php?id=12345 URLs. Not only does it tie you to a particular platform, but it means that your web server is going to have to dynamically handle these URLs in perpetuity.

Obviously, there are some things where that doesn't matter. Summary views aren't meant to be static, long-lived, or bookmarked. Ditto for comment-posting actions and the like. Moving from a doc?CreateDocument to a postComment.do in a form action isn't going to bother anyone.

There's another issue I haven't decided on, yet. Many blogging apps sort posts in a year/month directory structure, like 2006/02/mah-blog.html. The month/day division is a Good Thing - having all posts in a flat structure, hanging off of plink, screams 'database-retrieved'. A few thousand posts down the line, that virtual plink 'directory' is getting rather busy. As I said, I'm still thinking this through, because while it makes sense, I think it looks a bit uglier. Do aesthetics win over principles?

The jury's out.

How will I deal with incoming links to existing permalinks? Weeell, I don't have many incoming links to my posts, so I can get away with a simple app sitting on a /plink context, serving out 301 redirects for known permalinks and 404's with 'hey, try over there' comments for the rest. Most of my traffic apart from RSS feeds and faithful friends and family hitting the front page, is via Google for esoteric technical posts, and Google will sort itself out soon enough.

The only downside of the move, is going to be the eventual retirement of the colinp.dominodeveloper.net host name. When I started hosting with DDN, that was the only host you could use. Four months later I added thecorneroffice.org, and have used that in web comments etc ever since, but waaay over a year later, colinp.dominodeveloper.net still gets 4 times more traffic!