Once upon a time, web browsers were the only things that "spoke" http. So if you wanted to provide a file by http of some type that the HTML browser didn't know how to process, it would download the whole file, then hand it off to some other program. Or you could create a plugin which would live inside the browser and the browser could stream the data as it got downloaded.
This created a problem if you had a program that wanted to stream data from the internet but didn't want to live inside a browser as a plugin. For example, Real Audio supported non-browser-based streamed audio (and eventually video). So the way they came up to do this was to make an intermediate file--the .ram file. All the .ram file contained was the URL of the actual file to stream. The browser merrily downloaded the .ram file--nearly instantaneous--determined it didn't know what to do with .ram files, and that the Real Audio app was the app to hand such files to, and handed it off. Real Audio received the contents of the .ram file from the browser--having no clue what the original URL of the .ram file was, but the contents of the .ram file itself were a new URL which it then used to stream the actual data.
That was a fine, great, workaround hack.
IT IS TEN YEARS LATER. Perhaps browsers could now be aware of the fact that there ARE other programs that know how to do http themselves, and could make it possible to communicate a URL found in the browser directly to those apps, instead of assuming they are the only application which knows how to download via http.
For example, I visit a site that provides an index to a lot of internet-musician-authored mp3s. So there are a ton of links to mp3s. My choices under Firefox that I know of for what happens when I click on one of these mp3 links:
- Firefox downloads the entire mp3 and then hands it off to Winamp (or whatever other player)
- Apple's Quicktime plug-in handles mp3s as a plugin and immediate starts streaming. Except it always glitches the first few seconds, cuts off the ending, and its rewind won't rewind all the way to the beginning.
- Convince the site owner to on-the-fly generate a .m3u file for every link, said m3u file containing a link to the final .mp3. (m3u is a standard mp3 playlist format; Winamp handles URLs in them just fine, and I believe so do other mp3 players.) Similarly convince the owner of Songs to Wear Pants To, and numerous other mp3 sites.
I have this idea for this thing I'd like to create where lots of people create their own content of some special type, and put it on their webservers where it's available by http. Then this custom program downloads that data, which may even have hyperlinks to other data. Then since user-created content mostly sucks, you'd like for people to be able to have blogs where they, say, link to really good content. But when you click one of these links, I'm confronted with the problem that this leads to the html browser downloading all the data, which is just not what I want. (Imagine if you used a download manager to download an html page and then handed it off to an HTML browser, and that html page had references to separate CSS pages or script pages--the browser doesn't know the original URL so can't get at those pages!)
Dumb dumb dumb WTF.
(Then there's the fact that servers won't know this new type of data file by default, so they'll all try to serve it as text (WHAT THE FREAKING FUCK), so instead I'll have to name the file something like .zip, at which point, hey, my app won't even be the right app to hand things off to. The whole thing where the MIME types is determined by the server from non-MIME-specific file data (whether extension or magic cookie) would be a survivable stupidity if the default weren't text transcoding.)