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.