I'm just chuckling to myself. Last night I was telling Dave Winer about how we could bootstrap BitTorrent downloads into the Radio aggregator. At lunch today it occurred to me that there was a much simpler way than what we talked about. I get back from lunch and there's an note in my inbox from a fellow named Dan who is doing the exact same thing on his homegrown aggregator, in the exact same way. I've asked him if there's a writeup I can point to. I'll point to it if there is.


So here's the idea. BitTorrent (BT) downloads are initiated by launching the BT client against a file or URL. To Web browsing software, BT files look just like any other MIME file. You click on a hyperlink to a file having a Content-Type of application/x-bittorrent, typically ending in .torrent, the browser downloads the file, and launches the appropriate helper application. A key point is, the .torrent file is small, just a descriptor that tells BitTorrent how to get the large media file. The question is, how does this all fit into RSS?


In the news aggregator world, file downloads are specified as enclosures. It's a funny idea, downloading 1kb file using a system that was designed for 100MB media files. But the funniness is a red herring. We download the (small) .torrent file as an enclosure, and then launch the BT client against that file to get the (large) media file. The same motivator for enclosures---to have the downloading happen overnight while you're (hopefully) not sitting at the computer---applies. It's just the details that differ.


BT has a nice command line interface, btw. We just need to feed it appropriate --responsefile and --saveas arguments. The trick, at least on Windows, is dealing with client software that wants to spawn windows that don't know how to close themselves. Ideally we'd have a client that didn't spawn a window and that accepted a parameter that told it how long to continue running after completion of the download, to help other downloaders.