Digging into this enclosure issue, I realized that they are only defined in RSS 2.0 and I only had 0.91 feed. At the moment, I have both of them defined so that you can syndicate either the 0.91 version or the 2.0 version. If you want enclosures, it will have to be the 2.0. Thanks to Mike Mason, who has RSS 2.0 blosxom flavours available for download on his blog. That saved me some time, rather than have to write those myself.
Anyone out there using aggregators that support enclosures, I ask a favor of you. Could you please subscribe to the 2.0 version and tell me if the enclosures for the audioblog are working on your aggregator? I have tried it out myself via the iPodder script and it is not working that way. However, the more I use iPodder, the more I find little things that are funky with it. I’m not going to get too excited until I find out this isn’t working in others like Radio, etc.
I opted for simplicity with my blosxom plugin. I originally started to get complex, like defining a data directory and if you had an MP3 with the same filename as your current text entry, then it would be an enclosure for that post, etc. However there is nothing that says that the file you want to have the enclosure for is a local file to the webserver running blosxom. It might be hosted elsewhere or it might not even be yours. To make it as absolutely simple as possible, I opted for adding an element into my link tags. If, prior to the href portion of a link there is defined the attribute enclosure=”true”, then the file pointed to by this link will have an enclosure tag written for it. That was the absolutely most simple thing I could think of. Now, any file inside any post can be marked as something that gets an enclosure, and you just do it by marking up the link. Browsers and everything else will ignore this. In fact, I could have all the flavours that don’t use this just strip that out of the final HTML if I was so inclined.
Since I wanted to allow for offsite links, the only real issue was getting the filesize, which is a required element of the enclosure tag. I opted for the same kind of caching mechanism that is common in many plugins. There is a cache file on disk that maps an URL to its MIME type and size. On startup, the cache is read in. When it presents an enclosure tag, if there is nothing in the cache for this URL it uses LWP::Simple to get that information from the URL and then writes it back out to the cache. Any given URL should only have to have the head lookup done one single time, so it shouldn’t be too big a hit from either side. The very first RSS 2.0 load after a new post arrives with an enclosure will be slightly delayed while this HTTP HEAD request goes out and finds that info but after that it will be in the cache.
So, all the futzing is done with the infrastructure. When you are a geek, this is how you spend your Friday nights. From here on out, whenever I feel the mood I’ll make an audio post and everything will work just fine in the RSS world. I suppose there is no reason why I couldn’t alter it right now to make all my RSS feeds be 2.0. I don’t think that will break anything, but for the moment I think I’ll just stand pat while I experiment with all this. Again, if you have enclosure aggregators or scripts or the like, please try out my 2.0 feed with them and let me know if it works or not. Thank you.