Does your blog look like this?
Updated list of subscribe buttonsI've updated my list of subscribe buttons to include every feed reader known to man, and one known only to monkeys and algae. Click the button to the right for your reader to subscribe to this feed.
If things keep going the way they are, with every feed reader having their own subscribe button, we're going to need search forms to help people find the button for their feed reader! I can think of three solutions:
1) Ignore all but the most important feed readers (I don't like it).
2) A search form to find your subscribe button (obviously not good).
3) Devise a single method for subscribing that everyone supports so that it can be done with a single button.
#1 and #2 are lame solutions and won't be discussed further here. Attempts have been made at solution #3, but no far, I don't think they've succeeded. Some solutions send all subscription requests through a single internet server, which hands it off to the user's preferred service. Depending on one service, and giving it that much power, seems like a bad idea to me.
Another solution is to prefix the feed URL with "feed://" instead of "http://". The problem with that is that "feed" is not a transfer protocol, so it's technically incorrect. One quick example will illustrate why that matters. What if your feed is hosted on a secure server (an "https://" URL)? There's no way to include that in a "feed://" URL.
Another solution is to depend on the server to send the correct MIME media type in the Content-Type header when feeding up a feed (for example, application/rss+xml for an RSS 2.0 feed, or application/atom+xml for an Atom feed). The web browser retrieves the feed, sees that it's a feed, and hands it off to the feed reader. This is the technically correct solution, but it has two problems:
i think ur weird ...1) Not all servers serve feeds with the correct MIME media types.
2) When the browser hands the data off to the feed reader, it doesn't tell if the URL from which the feed was retrieved, so the feed reader doesn't know how to subscribe to future updates.
#2 has been solved in the Atom format by defining a link that points to the location from which the feed can be retrieved. Such a link looks like this, and since it's in the document rather than the headers, the feed reader is guaranteed to see it (if the feed includes it):
<link rel="self" type="application/atom+xml" href="http://example.com/myfeed.atom" />
What about problem #1? I think servers are just going to have to be upgraded to fix that one. It's not difficult. In fact, with some web server software like Apache, all you have to do is be sure you've got a reasonably recent version of the configuration file that controls the mapping from filename extensions to MIME media types (or use your .htaccess file to override the default setting) and make sure that your feed's filename extension is ".atom". If you're outputting the feed using a script, and thus the filename has to end with something like ".php", you just need to be sure that your script is outputting a content type header. For example, in PHP, include this line of code:
Header('Content-Type: application/atom+xml');
One last issue that occurs to me--a very important issue: Web browsers can be configured to hand off documents with particular MIME types to particular applications. But that won't do the job for web based feed readers like My Yahoo! For those, browsers must be configurable to send the URL of the feed to the feed reader's subscription script, ie., the browser need to be able to be told "if you encounter a document whose content type is application/atom+xml, post it's URL to http://myyahoo.example.com/subscribe.cgi".
January 24th, 2006 at 7:12 pm
i think ur weird ...