The Inside Track on Firefox Development.
« Battling Firefox Bloat | Main | Another Feed Question »
January 26, 2006
Feed Reader Questions
I have a few questions for users of client side feed readers, since I'm putting together the feed handling system for Firefox2:
- How do client side feed readers register themselves as the default handler for feeds? Register for various content types? If so, which ones? Use the feed: protocol? Do they do this at all? I want to be able to detect what a user's default is, if there is one.
- Is there a common repository on Windows that stores a list of all installed feed readers? (Not just the default). I want to be able to populate a list of available choices.
If the answer is "no" to number 1, I'm going to recommend feed readers register at least for the common RSS/Atom types... but obviously not for generic types like text/xml etc that are handled by the web browser. Firefox will detect that you are the handler of one of the more specific types and use that as a key.
Posted by ben at January 26, 2006 2:23 PM
Comments
I religously use netnewswire. It uses the Feed:// protocol (once you stop Safari attempting to make itself the default reader).
Posted by: Chris Parker at January 26, 2006 2:56 PM
Hi Ben,
I maintain an extension to allow users to make firefox integrate with their client side feed readers (web based ones too).
http://projects.koziarski.net/fyr/
My experience has been that most if not all of the desktop aggregators are now using the feed:// protocol.
Very few readers register for the RSS/ Atom MIME types. I believe this is largely because until atom 1.0 introduced link rel="self", the feed documents did not contain enough information for the aggregator to subscribe. So support for the feed:// protocol would probably be required.
Please also consider configuring web based aggregators. FYR's simple token replacement method has worked just fine.
I spent a while working with some aggregator developers, desktop and web based, and if you'd like any more information, drop me a line.
Posted by: Michael Koziarski at January 26, 2006 2:57 PM
Thunderbird supports (or at least tries to support) the feed protocol. That seems to me to be the best approach.
Posted by: Greg K Nicholson at January 26, 2006 3:14 PM
I can look for feed: protocol registrations, but since this is mostly a mac thing I think I should also check for content type registrations. I also expect that there will be at least one reader which deliberately does not support feed: because it misuses the transport to indicate content type (or class of content-types) ;-)
Posted by: Ben at January 26, 2006 3:18 PM
I hate the feed:// protocol. It's using http:// and should be treated as such.
Since feeds typically is text/xml, it should be based on sniffing the doc, presumably for <rss>.
Posted by: Robert Accettura at January 26, 2006 3:51 PM
I'd rather Ff (and Thunderbird) just be able to understand podcast feeds. Aside from some iTunes-specific stuff, which is in its own namespace where it can be ignored, it seems to be a standard RSS 2.0 feed.
Actually, now that I think about it, if you make Ff able to read a podcast feed, I'd appreciate it being able to pick up pcast:// URLs, since I'm pretty sure those only work on Mac.
Posted by: Jason at January 26, 2006 4:02 PM
Jason: I have a plan for that, insofar as sites _don't_ use pcast: or any other special abuse of the transport indicator ;-) If they do, the external protocol handler should take care of dispatching them to the appropriate handler automatically.
Posted by: Ben at January 26, 2006 4:07 PM
While I can argue about the appropriateness of using feed: links for weeks on end, that's not what matters here. For discovering the user's preferred aggregator, it's vastly more effective. I can imagine a program registering for the Atom and RSS content types but not as a feed: handler for political reasons, but out of 19 Windows clients I can't find one that actually does.
I'd say if (feed: handler) elseif (application/atom+xml handler) else (application/rss+xml handler) - a user is more likely to have switched from something that registered the mime-types to something that only took over feed: than the other way around.
And while I get the impression that Vista may be able to tell you about all the installed feed readers, until then there isn't anything that will (other than a user with an [Add] button that opens a filepicker).
Posted by: Phil Ringnalda at January 26, 2006 4:52 PM
One thing IE7 really has over Firefox is the friendly display of feeds instead of the raw XML that confuses 99.9% of the people that click on that little orange icon. As a bonus, they even allow you to subscribe to the feed directly from their friendly display. I hope to see a similar feature in Firefox 2. (I am assuming that's what you are working on by the questions you asked in this entry, if not, please consider it.) And of course, as with everything in Firefox, this friendly display should have the ability to be disabled via prefs.js.
Posted by: Andy at January 26, 2006 5:08 PM
Andy - that's what I'm working on. If you want to see the raw XML, you'll be able to do view->source (a continuing staple of the browser UI ;-)
Posted by: Ben at January 26, 2006 5:38 PM
I don't really have an idea about no. 1, but in no. 2 I know that WinXP maintains in its registry a list of browsers and mail agents, which a user can then choose in their's über-smart Start Menu (in a top part of it). AFAIK it is currently only used for thouse two app categories, but I read somewhere it can cover more types. I'm sure IE folks would agree with such usage.
Posted by: psz at January 26, 2006 6:11 PM
Wow, this is all a mess, isn't it? The right way to do it would have been to have application/rss+xml and an application/atom+xml MIME types that everyone used to serve their feeds. But no, some foolish person somewhere decided that it would be a good idea to use feed://. What were they thinking? The rest of the world has been using MIME types and helper apps for years. It's a system that _works_.
What happens in five years time, when a new protocol arrives and people want to serve feeds over it? Are they going to invent newfeed://? Grr...
Posted by: Gerv at January 27, 2006 2:49 AM
Well, it's not quite that simple: it started out as a way to syndicate content from one website on another website, not as a way to subscribe to weblogs, then it just grew and multiplied without any official standard to the point that application/rss+xml is unregisterable, and the most popular RSS "spec" is frozen without having an element whose content is "my URL, the only thing that you want when you're a handler given a local copy from a browser" so some people are borrowing one from Atom but mostly if you are an application/rss+xml handler you have to parse out the URL for the HTML page, and then use autodiscovery from it to get to the URL your user wants to subscribe to. It really has more in common with streaming MP3s, where you link to a playlist file that just contains the real URL, but it's way too late in the game to switch to that.
All that is another reason to prefer finding the feed: handling application, though: the application/rss+xml handler may well be a stub that only knows how to take a local file and discover the URL to pass on to another program, while you know the feed: handler expects a URL on the commandline.
Posted by: Phil Ringnalda at January 27, 2006 8:45 AM
©1997-2006 Ben Goodger. All Rights Reserved.
Opinions expressed here are my own, and not those of any organization that I may be affiliated with.
Reload icon is © Stephen Horlander;
Firefox logo is by
Jon Hicks, and is a
trademark of The Mozilla Foundation.
GetFirefox buttons are from rakaz
