Although I don't build an aggregator and I'm not planning to build one in the future, the ideas and problems of finding feeds interest me. Probably because they are related to URIs and MIME types, two fantastic topics to create permathreads anytime you want, on a feed mailing list (like atom-syntax). Besides that the post is quite interesting, there are also 22 comments from people who seem to know what they are talking about, it was worth the read.
Suggestions include telling the browser what to with the MIME type. This is of course suboptimal, since the user has to know a feed has a different URI, the user has to configure the browser if it can't be automatically configured. People would actually have to know about MIME types in the first place, but that might be a browser problem, not ours. Of course, when you have a browser like Opera (and soon, a mail client like Mozilla Thunderbird), with a feed reader on board, you don't have to worry. Point the thing to it and you are ready. One of the worst suggestions is (was) the 'feed' protocol URI scheme:
You might think it is a good suggestion, but in that case you should compare it to a 'jpg' URI scheme, see? It just sucks; MIME types handle the type of content, not URI schemes. Please ban it from the internet. The best solution is autodiscovery. Although only Atom has submitted a specification to the IETF. I guess actual implementations support other TYPE attribute values for LINK elements with rel="alternate", like type="application/rdf+xml".
There might be other solutions, but I think autodiscovery is simply brilliant and when I'm ever going to do a revision of the perfect weblog system it will be a template requirement or some such. I especially like Atom because of these things. Attention to detail is a must.
If you use the new Firefox nightly, which has an built in RSS aggregator and checker, you get something like this
For the full article about Firefox RSS intergration ("Livemarks"), look here. I hope I didn't miss-interpetet your post.
One of the worst suggestions is (was) the 'feed' protocol ... You might think it is a good suggestion, but in that case you should compare it to a 'jpg' protocol, see? It just sucks; MIME types handle the type of content, not protocols.
It's not a protocol; it's just a URI scheme. Furthermore, since the feed: URI scheme is just a way of saying "the http: version of this URL is a newsfeed", Content-types still apply, and you can have any kind of newsfeed you like represented by a feed: URI (ie. it doesn't actually decide the kind of content). It's just a form of auto-discovery: any resource identified by a feed: URIs will be some kind of newsfeed.
I've never entirely understood the whole autodiscovery thing. What's the point? How come there's not an autodiscovery need/problem for other types of content? I'm not knocking it, I just don't grasp it. I'm missing something here.
You understand that RSS autodisco existed long before Atom was a thought.
I've never entirely understood the whole autodiscovery thing. What's the point?
The point of autodiscovery is that a browser (be it an RSS/Atom aggregator or a regular browser with some sort of RSS/Atom support, like Opera) can automatically find the URI of the feed that represents the page you're looking at.
The problem this represents is that the alternate representation of this exact page, for example, naturally isn't a feed, but a single RSS ITEM or Atom ENTRY document. This is something people still haven't agreed on, but I think it's very logical that an alternate representation of something should give the exact same content, only with some possible chrome and in another format. Another language is of course also okay if it is stated in the LINK tag.
Autodiscovery of RSS/Atom feeds is nothing more than "autodiscovery" of "next", "prev", "home", "up", "down" etc. URI's. The only difference is that while the content at the end of a "next" or "prev" LINK URI is 99% certain to be (X)HTML, the content at the end of an "alternate" LINK URI is 99% certain to not be (X)HTML. And, while "next" and "prev" usually navigates to another resource than the one you're looking at, "alternate" navigates to another representation of the same resource.
Asbjørn, you forget languages. Alternate languages are common and mostly in the same format. (Your point is clear though.)
Another language is of course also okay if it is stated in the
LINKtag.
That's what I wrote about languages. What is it that I forgot, Anne? :-)
