Pete Hopkins (here, here) and Steven Wood (here) are lobbying for support for subscription links in the format
Steven even posted the necessary registry entries for Internet Explorer to wire up an application to respond to a user clicking a link like this. So, for example, NewsGator could add a subscription whenever a user clicks on a feed:// link.
This seems like a reasonable idea to me…with the obvious benefit that a user could just click on the link, and the aggregator could add a subscription to the feed. As opposed to the situation today, where if the user clicks on a feed link, they’ll see (at best) a page full of XML. Now of course they can right-click on an existing link, and select “Subscribe in NewsGator”, but supporting a left-click subscription as well might be nice.
Other aggregators support a subscription link in a format like http://localhost:5678/…, but I dislike the idea of applications listening on certain ports like this. The feed:// idea is much more attractive, IMHO.
I like the feed:// idea, but I think the safe default should be to preview the feed in your aggregator rather than automatically subscribing. Either way, it seems much safer than having aggregators listening on ports! The thought of pop-up windows doing a redirect to localhost:5678 and auto-subscribing me to multiple all-pop-up-all-the-time RSS feeds seems like a good reason to switch.
Ah…the preview idea seems like a good one. So when the user clicks on a feed:// link, we could pop up a window that has info about the feed (title, author, etc.), and confirm the subscription. I like it.
And you’re sure right about the popups and the localhost thing!
Exactly, I’m imagining that I could click a feed:// link and it would even let me preview the current posts in the feed before I confirmed the subscription.
Getting all the popular aggregators to support feed:// seems like the big challenge now.
I like the feed:// idea, as well. Currently, users only get the right click NewsGator option in IE, while other browsers don’t get anything. With feed://, any browser would be able to add (or preview) the specified feed in the default aggregator.
WinRSS has support for the feed:// and rss:// protocols.
We have published a brief draft of the available syntax at:
Please send us your suggestions for improvements.
I agree that it’s better than having an aggregator listen on a port, but I also agree with Richard Tallent – the proposed uri syntax just looks wrong. Also, does this mean that the
I agree that it’s better than having an aggregator listen on a port, but I also agree with Richard Tallent – the proposed uri syntax just looks wrong. Also, does this mean that the <link rel=”alternate” type=”application/rss+xml” could/should now refer to a feed:/ / uri?
Interesting question. I would say “no” if the browser could be made to know to pass an http (or whatever) URL to the aggregator when it showed up in a link with that MIME type. But I don’t know how you’d go about doing that…
It seems to me that link is primarily used by aggregators parsing the HTML to find a feed to subscribe to, in which case you don’t need the feed: bit.
But, if the user could easily “click” on the URLs mentioned in link tags and the browser didn’t know how to handle them specially, yes, they should use “feed:”
I’m not sure I like feed:// (there are tons of semi-proprietary protocol prefixes already, so maybe I’m fighting a losing battle) as compared to just having syndication feeds have their own MIME types, which would be handled by “players” just like media files are.
Anil, I think you’ve convinced me! Registering a handler for the text/rss (or whatever) mime type does seem a lot cleaner than feed://. Plus, it doesn’t make links appear defective for people who don’t have RSS agregators installed. The preview/confirm step could still take place exactly as I described above for feed://.
Why not just use extensions and mime types? Seems to work for everything else.
I’m not convinced MIME types will work. I might be wrong, but I’ve put my thoughts out here: http://pirate.typepad.com/blog/2003/09/problems_with_m.html
(Also note that feed: and correct MIME types are not mutually exclusive… in fact, you want correct MIME types so an aggregator knows what format it’s dealing with.)
I agree in principle that a MIME type is probably appropriate, and that we’re not defining a new protocol. A few comments:
1. The MIME type suffers from a couple of problems. First, publishers would have to support this – and some folks who have limited access to their servers cannot accomplish this. This alone rules out this option.
2. Second problem with MIME types is what Pete said – we’d have to come up with an intermediate “discovery” file which would be served with the new MIME type. Ugh…one more thing for publishers to implement.
3. I’m not sure local file: or other types of links could be served with a specific MIME type, which rules out the use case of feed links in, say, a CHM file.
4. As far as the protocol argument, we’re not really defining a new protocol here…this is merely a simple hook into the browser to allow aggregators to get ahold of a feed URL. And it’s simple to implement, for both publisher and consumer.
I meant to say in the previous comment that while I agree in principle about the MIME type et al, I think there are a number of problems with that approach, some of which cannot be easily solved…so I still like the feed: approach, I think.
I’m fully in support of feed:// urls. And I’ll be happy to see that they get supported in Feedster if this picks up momentum.
Mime types are elegant, wonderful, etc. And I hate them with the passion reserved for a 1000 rotting dead toads. Anyone who’s ever browsed movable type urls with Mozilla knows exactly what I mean. Everything in MT has mime types and since none of us have registered applications, we all end up viewing simple xml data in Notepad, VIM, etc. That’s stoopid. Its such a problem that there is a fairly active Mozilla project devoted to letting the user override the mime types and say “well that may be what they say but here’s what application I really want you to use”.
Greg has mentioned three points against MIME types, any of which would be sufficient to rule it out, in my opinion, but I’ll offer a fourth problem: RSS feeds are generally speaking XML (or RDF) files, and as such, should be served up as text/xml … unless we’re going to start making text/xml/rss and such. You can’t have your agregator handling all xml files, and I don’t think we should be serving XML files with an RSS-specific MIME type if we don’t want to break parsers. (Microsoft’s XML parser, for instance, will not correctly handle encodings if you use a non xml MIME type).
However, I do have the solution for the fugly file://http:// thing, and I can’t understand why it’s not obvious to every one. (Hint: try typing a URL into google’s search and see what it looks like in the resulting URL address)
I actually went ahead and wrote up a semi-formal proposal. Tell me what you think.
The feed:// and rss:// idea is good, We can and will implement this into our RSS Development tool, what worries me is what the readers will do to eachother, eg. what still happens with email clients (bla bla is not the standard email client, do you want to become so…), but then again this is a minor moan to compared that we are heading to a standard ;)
Why do you need the // in feed://
From what I remember from the URI definition, it isn’t needed (like mailto:).
You’re right. You use feed:// when you don’t specify the transport scheme (it defaults to HTTP). When you do, you write feed:http://
After some lively discussion yesterday (more references below), here are my thoughts. We need to come up with…[more]
Fun Stealth Disco via Joi Ito Themes Online – TV series themes in MP3 format via The Cartoonist Software…[more]
Subscriptions with feed://: There’s a movement afoot to add a “standard” protocol of “feed://” for subscribing to RSS feeds. This item includes a link to the Microsoft MSDN article that explains how to link an application to a URL protocol,…[more]
Via Greg Reinacker (author of NewsGator): “This seems like a reasonable idea to me…with the obvious benefit that a user could just click on the link, and the aggregator could add a subscription to the feed. As opposed to the situation today, where if the user clicks on a feed link, they’ll see (at best) a page full of XML.” Further comments can be found in a later post. Genius idea that, once again, will rely on the support of news aggregator programmers….[more]
I’m not convinced that this is the right way to do.
I am not aware of any other protocol prefixes which actually initiate a change in client state (from not subscribed to subscribed). If this protocol simply meant “view”, I would be one less objection away from liking it.
How does the protocol handler deal with multiple aggregators on a single machine? Remember a couple of years ago when each media player (WinAmp, Real, WindowsMedia) would step on the registry and launch settings of the others? Remember what a federal case this turned in to? We have the makings of something similar here (unless I have misunderstood something).
Interesting point about the change in client state; however, if we again come back to the goal here (a browser hook for subscription), it seems reasonable in this case, IMHO. Anyone else have thoughts about this?
On the multiple aggregator question, I think the only real solution is for aggregators to detect at startup that they are not registered for feed:, and ask the user if they would like to switch the registration. Similar to how most of the media players do it today.
Jeff: Multiple aggregators are no more a problem than multiple HTML browsers. If you’ve got two installed, one handles “automatic” subscriptions, and the other either imports those subs via OPML or has them added manually at the whim of the user.
RSS feeds *must* be served as application/rss+xml. On web servers that MIME type should be associated with the extension .rss, or it should be forced if the feed has a .xml (or whatever) extension. On the client the application/rss+xml MIME type should be associated with the favorite aggregator (most aggregators do that by default), so that the program is invoked when accessing the feed.
Many website (including this one) do serve feeds with text/xml or text/plain MIME types, even if they have a .rss extension. That’s wrong!
There is no need for a new protocol, because feeds are actually served via http. Just configure the correct MIME type for them.
Gabriele, did you read the comments about 15 comments up about MIME types? We’ve been down this road. They won’t work in this context. They won’t be adopted. Let’s accept it and move on.
Greg, would you serve a Flash application or an MPEG movie as text/plain? Of course not! We can’t change the world for RSS feeds! If the hosting provider doesn’t configure its web server to support the application/rss+xml MIME type, try using php or asp or whatever for the feed. Otherwise, just ask if they can configure that type for you. Sorry, but I think this is the only way.
Gabriele, of course I wouldn’t serve up a movie as text/plain. That’s different, though, because the movie player application needs the content of the file. In the RSS case, the application just needs the URL of the file. If we register a MIME type, the RSS reader would get the RSS, which isn’t useful AT ALL without the URL. So we’d need a discovery file that’s served with application/rss+autodisco type (or something along those lines), which is even more work for the publisher.
Not to mention what Joel said above about XML parsers barfing on non-xml types.
Honestly, I agree, a new MIME type is probably a good thing to do…but widespread adoption will be nearly impossible. Let’s go with something that publishers can do easily, and will do.
Remember, we’re not designing a protocol – it’s a browser hook. More in the follow-up post here.
The last umpteen comments I’ve heard regarding “feed:” is that we should be using MIME types instead…[more]
Another protocol scheme is silly considering we just need to load a resource at a well known location.
Joe Gregorio has a good post about MIME types and the feed: scheme:. There has been much talk today, and in the…[more]
Why not simply link to a file containing only the URL of the feed and using a specific MIME-type? That’s how it works for internet radio.
Greg, Hopefully, you’ve seen my efforts to move Joe’s work forward. I’ve convinced two vendors, each of the last two days. I’ve also posted samples for you to play with and incorporate into your aggregator. I hope you’ll help. I call it USM.
In my opinon we should not hack about adding pseudo protocol’s like feed:// – its just ugly. However I feel a few obvious things have not been said.
The problem seems to be that the RSS standard(s) are broken. Why not simply fix them by adding a url/base element?
The problems using MIME seem to stem from broken software, not broken MIME. MIME is absolutely meant to do this stuff, so why not fix the blogging tools to emit the appropriate headers? It’s not that hard. Also any ISP that doesn’t server up an rss+xml MIME header for *.rss files has a broken configuration – tell them to fix it.
Why not fix the problem rather than hack around it?
Pingback: When open-uri can’t convert Hash into String — another time it happens « catapult-creative.com