Nick makes some points about Really Simple Subscription. I linked to Phil yesterday, who wrote a little rant about centralized subscription. Nick basically says the same thing (see also The solution to the Yahoo problem) and then continues with some proposal he fancies for feed detection. Once again it seems he is totally ignorant to existing solutions. He does acknowledge it is not the perfect solution, though right after that he states that there is no such thing. Well, there is a better solution. One that does not require an update of some popular online aggregators. One that does not require an update from browsers, like Opera and Firefox. One that is actually quite widely used, and default in most weblogging services. Even Nick's weblog has one.
Ah, you know what I am talking about now? Exactly, the orange XML button. Euh, feed autodiscovery. Using the LINK element to point to a feed is the (pseudo) standard (there are some IETF drafts) that works.
Now what exactly is Nick saying? Should we use new methods, or should we use existing methods?
I'm proposing that we go ahead with something that already works and has already been implemented by many RSS readers.
- Nick Bradbury, in the comments on that entry
And again feed discovery only talks about LINK elements, not A elements. Everybody already has an orange XML button, with an A link pointing to the feed. Why not just add the rel and type attributes to that element.
Why not just use a unified file extension like .rss, then we can be certain that it's a feed. No matter how you link, with a tag, or rel link or just list the URL in plain text mode.
Extensions are meaningless on the web, didn't you know?
Sjoerd: how to make a difference between you linking to a feed you are subscribed to, and the feed for the page you are on? rel="alternate" in the context of a body-element and rel="alternate" in head-context seem to have different purpose to me.
Robert: nice idea, but the rel attribute is specified as: This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.
So the target of a link with rel="alternate" in the head or the body is an alternate of the current document. For subscriptions you'd need a new rel value.
Feed auto-discovery is not a solution to the problem being discussed, at least not yet.
Auto-discovery refers to detecting link elements which point to RSS feeds, which is a separate (albeit related) issue. FeedDemon and most other RSS readers already support auto-discovery, but *today* this doesn't enable people to click a little orange button in their browser to subscribe to a feed (unless they're browsing inside FeedDemon).
In a perfect world, every browser would support feed auto-discovery and enable you to subscribe without clicking a button. Once that happens, we can forget all about this discussion. But in the meantime, we still need something that works.
But if that lil' orange button in Firefox can be used to subscribe in Bloglines, surely one can write an extension for this kind of functionality concerning FeedDemon? (Or maybe not so, I'm not that into the Mozilla security model...) But, anyway: maybe a feed scheme is a nice workaround for you, but since we're still talking about an HTTP request, it doesn't make much sense to me to not use the http scheme. Besides, it would be rather impossible to point to a feed on a FTP server, and I am subscribed to some of those. (For software updates, by example MySQL has such an Atom feed, as far as I can remember.)
RSS stands for Really Simple Syndication. It used to stand for Rich Site Summary, which I prefer.
Robbert: Feed Your Reader is what you want.
Aren't things like Feed Your Reader the solution? Perhaps they could spot links to feeds in addition to autodiscovery, but there isn't much else which can be done.
Mark: not what I want, but what Nick needs. Well, that's only IMHO, of course.
FYI: LiveLines has an option called Find RSS feeds without <link> tags.