Enclosures in Atom

In a comment Pete Prodoehl mentioned how he also hasn’t found anything definitive about enclosures or similar functionality in Atom. I went digging about and found this link to a relatively recent blog posting about it. One of the commentors had several links to other discussions of the subject, and I want to talk about one of them.

Lucas Gonze wrote a post about why he was removing enclosure support from Webjay playlists. I’m assuming that his arguments against the enclosure tags are colored by that project, and maybe not necessarily about the tag in general. Dunno, I’ll track him back and if he’d like to respond and clarify here he is welcome to. (Unlike a certain person in the enclosure world, I won’t get mad about it.) The bottom two points on his list, about not needing the filesize and MIME type in the enclosure tag I’m not going into because I don’t disagree with them. I actually do use the MIME type attribute in get_enclosures but if it didn’t exist there I would just use the one from the HTTP response. In fact, I probably should anyway, just in case the value in the enclosure is wrong.

Here are his arguments:

It causes users to download big files that they will never listen to or watch, creating pointless overload on web hosts.

This might be an issue in the Webjay situation or other meta-feeds that are collections of other RSS feeds. This is not a criticism of enclosures per se but of using aggregating enclosures on a feed where you don’t want all the files. I’m aggregating 8 feeds now with get_enclosures, and all of them are ones with a high probability that I want to listen to everything. There might be an individual item on IT Conversations that I download and after listening to a little bit decide not to finish, but that is a rarity. Almost everything I am aggregating are feeds that I want to listen to every single item. This argument strikes me as less a statement about enclosures and more another way of stating the common sense notion “Don’t automatically get enclosures on a feed unless you are pretty sure you are going to want them.”

It doesn’t allow us to credit the MP3 host, so we can’t satisfy the netiquette of always linking back.

I don’t understand this. I’m not sure what kind of aggregator he’s using where he can’t tell what feed the MP3 came from. I certainly can, because they end up in a playlist and directory based on what feed they came from. Even if someone adds an enclosure tag to a site not their own, that will show up as coming from the feed where the tag originated. If you want to credit it, you can always look at the HTML or RSS from that feed to find out what it was. In the case where a desktop aggregator is automatically doing it, the aggregator should know this information as well.

For broadband users, MP3s are not big enough to need advance caching in the first place.

Here’s the biggest miss of all, not understanding what we like so much about the “iPod platform.” It’s not that I need advance caching because it takes so long to get down the pipe for me (it doesn’t), it’s that I want automatic handling of items of (highly probable) interest to me. The thing we are trying to conserve here isn’t optimizing bandwidth throughput, it’s my scarce time and attention. I don’t want to have to think about checking Adam Curry’s feed or IT Conversations to see if new MP3s are up, I want them to magically appear on my hard disk and in my iTunes playlist. If I had an iPod, I’d want them synced up automatically so they were there when I left the house, whether I knew they were there or not. It’s why people like TiVos, it’s why people like RSS aggregators, and it’s why I like the “iPod platform.” Defining up front what my interests are and then letting the robot deliver me goodies that match without further effort on my part is highly appealing to me. I do this with RadioLover for radio streams, I do this with get_enclosures for RSS enclosure feeds. In both cases, I’m deliriously happy with my results.

There you have my reasoning why I think these arguments are not applicable in explaining why we don’t need enclosures or enclosure-like functionality in Atom. From that top link, it looks like the Atom link tag and its “rel” attribute are what they are planning on possibly using for this kind of feature. I can’t tell from the discussion on this blog post where in the process it is. The deal is that whatever the mechanism, a link tag with rel=”enclosure” or with rel=”related” or whatever they do, it just needs to be defined and supported. It sounds like the Atom community is still divided on whether this even is of value, much less what the definition is. That’s not great news to me if true, so I hope I am misreading the situation.

Published by


Dave Slusher is a blogger, podcaster, computer programmer, author, science fiction fan and father. Member of the Podcast Hall of Fame class of 2022.

4 thoughts on “Enclosures in Atom”

  1. The whole “enclosures *could* be a bad idea, or used for malicious purposes” thing has been going for years now… Sure, they can be misused, or used poorly, like anything else out there. As far as non-audio content, I’d love an RSS feed from Sourceforge with enclosures for the projects I like. It would be great to have a new version of iTerm or Audacity automagically downloaded each time there’s a new release. I’m going to download it anyway, right? People often write scripts to download nightly builds of projects they like, how about a standard format for that, rss feeds with enclosures?

    The concerns that Lucas has might be valid, and it’s good to hear feedback on enclosures, and as we keep doing this, I’m sure we’ll hit other issues along the way. Heck, that’s half the excitement of this whole thing…

  2. Dave says:

    Pete, I went to leave a comment on your blog but you don’t have them! I just listened to your audioblog, and wondered why you need three applications to do the music bed. Why not just import the music into a second track? You can do multitracking in Audacity pretty easily. At a few points your audio got jittery, like your computer had hit the limit of resources and couldn’t record fast enough. You could get rid of the music playing, at the very least, and add it later.

    All of these statements against enclosures are actually statements against client behavior. I’m trying to be open-minded about these arguments, but there is a certain “no shit sherlock” aspect to some of it. If you subscribe to a feed that has enclosures to wildly disparate sources and automatically aggregate it, you’ll get wildly disparate downloads. Yes, OK. Does that mean that the people who want to subscribe to a tightly focused feed shouldn’t be able to? And the whole DOS thing about how you could insert a link to a source and have all the autobots hammer it, how exactly is this different to the HTML world? If Boing Boing links to a video, it is going to get hammered too without enclosures and autobots.

    I’m going to sleep on this, audioblog about it tomorrow and maybe type up my thoughts Wednesday. It’s a conversation worth having, but thus far the counterarguments don’t move me much.

  3. Jeff Winkler says:

    Here’s a thought…for those with broadband, but no ipod, the ipodder/getenclosure script, could just add a -streaming entry- (IITURLTrack, not IITFileOrCDTrack) to iTunes. Simple enough, and satisfies the “inbox” / there-when-you-awake functionality.

    (I never know whether to put my email in these comment fields… whether it’ll be public for the spammers to harvest or not)

  4. Dave says:

    Jeff, that’s a downright GREAT idea. I’m thinking about ways to add configuration simply to the subscription file in my get_enclosures script. Just a simple toggle that says “download” or “stream” would work very well.

Comments are closed.