Since it is the season, I’ve done a tiny bit of Christmas redesigning. Hope it appeals.

I’ve been fairly busy this week, so posts have been thin on the ground. Real posting should reemerge tonight or tomorrow (it is the end of term after all).

A brand spanking new Atom snapshot is out (Atom 0.3 examples are available on diveintomark).

Due to FTP problems, I can’t upload the new templates at this moment, but I’ll at least talk about what will change.

To be honest, not a lot has changed. The link tag (feed level, and entry level) has changed in syntax (it’s now an empty tag). It also now requires a rel attribute (generally going to be set to “alternate”) and a type attribute.

The former could allow some interesting and smart parsing of documents (once the rel values are bulked out). The latter seems utterly useless. It doesn’t take into account multiple representations (one of the lovely aspects of a URI), or allow for content without a registered media type. It adds nothing (except a lot of extra bytes on a feed).

The new mode attribute will make feeds easier to parse, but seems to be lacking a plain text value (currently acceptable values are xml, escaped and base64).

That’s really about it. I added type attributes, changed some syntax and got absolutely no returns from it. At the moment, that particular attribute looks like bloat.

A reasonably large random link post today:

• Towers Of Hanoi – The classic puzzle in dozens of different computer languages, including an OS designed to solve the puzzle,
• Ocarina Of Time 2D – Someone is recreating the classic Zelda 64, in 2 dimensions. It looks quite nice, in a retro sort of way,
• Blogshares is gone back – After the recent closing of Blogshares, the site is now back with new management. It’s a fun game, in the short term,
• Atom Info Proposal – A proposal to make Atom readable in browsers (and by means of an extra tag and CSS. Why not just cut that down to using an XSL processing instruction? Makes sense to me,
• Ideogram Maker – Decide what various ideograms mean. Via Kevan,
• New IE bug – A very nasty Internet Explorer bug, making it a lot less safe to enter important details into that browser. Why does anyone still use it? It is garbage,
• How Not To Blog – Starting a blog? Pay attention to most of these rules and you’ll be fine, possibly even interesting,
• Find MIDIs – An excellent resource for finding MIDI files,
• Free Flight – A very absorbing, 3d paper plane flying program. It’s in shockwave, and is very relaxing,
• Airspeed Velocity Of An Unladen Swallow – Someone finally figured out the airspeed velocity of an unladen swallow. Pythoners worldwide rejoice.

And I’m done.

You should be able to change feed URLs in Luke Hutteman‘s Sharpreader without any hassle. You can’t. Here’s how you do it:

1. Close SharpReader, making sure it is completely gone and not just hiding in the SysTray.
2. Open your SharpReader data directory. On Windows XP, this will be something like “C:Documents and Settings%USER%Application DataSharpReader”, where %USER% is your username.
3. Open the file called subscriptions.xml in a text editor (Notepad will do fine). It contains the list of all your current subscriptions. Find the line which applies to the feed you want to change and change it to the new URL. Save the file and close it.
4. Open the subdirectory called “cache”. There will be a list of XML files. Their names correspond to the feed they are caching. If you updated the feed name, change it here as well. If you updated the feed’s extension, things are trickier. If it has been changed to .xml, remove the old extension from the cached file name. If it has been changed from .xml, you will need to add the new extension to the end of the file name (it will not currently have a .xml extension).
5. Restart SharpReader.

That’s what works for me, but as protection for me try this at your own risk.

There are three ways to reasonably serve up RSS, listed here in order of preference:

1. application/rss+xml
2. application/xml
3. text/xml

Since the first is the type we say we’re serving in the link tag (despite that type not being a real MIME type), that is the one we should probably pick to serve our feeds as. The problem is that browsers (rightly) refuse to display application/rss+xml. Instead, they try to download it or pass it to another viewer.

This behaviour doesn’t help someone who doesn’t know what an RSS feed does (a problem that needs addressed). They will see something they do not understand being downloaded and abort. Not good. To aid in this, it would be nice for the user to see the styled feed (my RSS 2.0 feed already has CSS styling).

Two thoughts occurred to me: “Are there any workarounds?” and “How are others serving their RSS feeds?”.

Changing the content-type to application/xml fixes the visibility problem, but means that feeds are inconsistent with the link tag. In turn, changing the link tag to suit the new content-type isn’t feasible. There are dozens of aggregators who need to see application/rss+xml in the link tag to do auto-discovery properly.

Step 2 was to see how others serve their feeds. The results were disconcerting, at best. Jacques Distler and Anne van Kesteren both use text/xml, Mark Pilgrim uses application/xml, and Sam Ruby uses application/xml for RSS 0.91 and application/rss+xml for RSS 2.0.

Ouch.

In the end, it’s probably best to settle on the middle option: application/xml. Why? It provides visibility, is the parent of the “correct” MIME type (if you see these things as hierarchical), and it is a real MIME type.

The situation is hardly ideal, but it’s the one we have.

As an aside, my RSS feeds now have a new extension (.rss, rather than .xml). I’ll be doing a transparent redirect for now, in a month or so I’ll make it explicit, and a month after that I might remove the old style entirely. Please update your subscriptions now to avoid disappointment later.