February 4, 2006
@ 07:55 PM
Comments [5]
Feedback on Windows RSS Platform from the Developer of RSS Bandit

Nick Bradbury has a post entitled Feedback on IE7 Beta 2 from the Developer of FeedDemon where he gives a lot of good feedback on the recently released IE 7 beta from his perspective as the developer of an RSS reader. Although I've given some feedback on the RSS reading functionality of  the IE 7 beta, I realize it would be more valuable to give my thoughts on the Winows RSS platform since this is supposed to make the job of people like me who've built RSS readers better. Below is a smattering of feedback divided into pros and cons of using the Windows RSS platform versus using the version we've built for RSS Bandit. Note that as Nick says in his post given that I've already written a lot of the ugly code needed to handle feed downloading, caching, parsing, etc. actually switching to use the Windows RSS platform is a load of unnecessary work for me. My feedback is based on the kind of support I'd need from the platform to implement the scenarios currently supported by RSS Bandit .

PRO

  • COM API  was very straightforward to interact with from  .NET applications
  • Built-in support for downloading enclosures in the background is nice
  • Good support for asynchronously downloading feeds. This means application developers don't need to write a bunch of multithreaded/asynchronous code themselves. That is definitely a godsend.
  • One can serialize feed objects to  XML

CON

  • No support for application specific feeds. The Common Feed List assumes that user needs to use the same list of feeds in the various applications used for subscribing to feeds. I think this assumption is fundamentally flawed. I might use one application for downloading podcasts (e.g. iTunes), another for reading blogs (e.g. RSS Bandit), and yet another for browsing photo feeds. Since it doesn't make sense for my blogs to show up in iTunes, it would be cool if I could identify either the type of feed (podcast, text-based, etc) or the favored application for reading the feed via the API.
  • No support for password protected feeds. The number of password protected feeds on the Web continues to grow, Web sites such as GMail and LiveJournal provide authenticated feeds for users today. As the usage of syndication technologies like RSS continues to grow, the need to support authentication by feed readers will also grow as well. I can imagine a day when I can subscribe to a password protected feed from my bank or credit card company. Not having support for this today is a non-starter.
  • Support for obtaining XML elements which aren't supported by the API. It would be nice if there was a property for obtaining extension elements in a feed that didn't involve having to convert the feed object to XML then using XPath. Being able to perform a call like  Feed.GetItem("http://wellformedweb.org/CommentAPI/ ", "commentRss") to get an element which isn't mapped to a property in the Feed object is a lot more desirable than writing DOM or XPath code to extract that element from the results of calling Feed.Xml
  • No ability to append application specific metadata to feeds. RSS Bandit supports notions like flagging items and we'd need some way to indicate that items are flagged if we are using the API.

Most of this is just based on reading the Using the Microsoft Feeds API document on MSDN. I'm sure I'd have more feedback if I took a pass at replacing all the feed processing code in RSS Bandit with the Windows RSS platform. However I don't think I'll have time to do that anytime soon.


 

Categories: Syndication Technology
Tracked by:
nhanson [Trackback]
http://tallist.com/bib/bagofurls/2006/02/12/windows-rss-platform-ala-carte-micro... [Pingback]
"IE7 RC1 can't update Password Protected Feeds" (Scott Hanselman's Computer Zen) [Trackback]
http://www.hanselman.com/blog/IE7RC1CantUpdatePasswordProtectedFeeds.aspx [Pingback]
http://blog.jonudell.net/2007/03/27/authenticated-rss-feeds/ [Pingback]
« The Difference Between Microsoft and O'R... | Home | Firefox Annoyance »
Saturday, 04 February 2006 20:59:24 (GMT Standard Time, UTC+00:00)
While I see your point re. the limitations of a Common Feed List, I'm not sure application-specific feeds is the right approach to fixing it. Rather than associating feeds with applications, wouldn't it be more useful to provide lots of metadata with each feed resource, and then let the application decide whether or not it is an appropriate handler. i.e. go declarative, loosely-coupled.

Naturally I'd use RDF (and incidentally there are now 5+ APIs for C#/.Net), but perhaps WinFS maight have something to offer..?
Danny
Saturday, 04 February 2006 21:46:36 (GMT Standard Time, UTC+00:00)
I also recently watched a videocast in which the head of the RSS team was claiming they "normalized" everything to RSS 2.0. How do you normalize something like say an atom:author to an RSS author, or the wide selection of atom:link types to RSS's single link element? Maybe there's some way to bypass their normalization and access the source data directly, but then what's the point of using their API?

Add to that their claim (I havent' verified this) that they won't support feeds with even the smallest of XML errors. Even worse their inability (I have verified this) to subscribe to feeds that have nothing wrong with them. Admittedly this is still a beta, but they're going to have to do a whole lot better if they expect this to be the one true feed processor.
James Holderness
Sunday, 05 February 2006 04:57:26 (GMT Standard Time, UTC+00:00)
@Danny: I agree with you 100%

@James: Atom is an evolving standard whereas RSS is pretty much fixed. It does make more sense to implement a fixed subset in an API then a moving superset. As Dare noted though they really should provide a mechanism to access the unsupported elements within the API. Even if they do not however they DO provide the XML source so you CAN "bypass their normalization". Even if you were forced to do so the point of using the API would be to access a common store that isn't specific to your application and the synchronization and other features it provides. I still think that's worthwhile.

As for their not supporting invalid XML I think that's GREAT, maybe if a large userbase can't access an invalid feed the provider will actually FIX it, encouraging invalid XML feeds by ignoring their errors helps no one. I wouldn't expect an application developer to take a stand as the users will simply go elsewhere but if they can point their finger at MS when the feeds don't work and explain to their users that if they don't use the MS API then their feeds won't be shared across applications then all the better. I suspect your inability to subscribe to a feed with nothing wrong with it is probably a bug, have you reported it? As you said, it IS a beta.
Nick Hanson
Sunday, 05 February 2006 18:48:10 (GMT Standard Time, UTC+00:00)
"No support for application specific feeds. The Common Feed List assumes that user needs to use the same list of feeds in the various applications used for subscribing to feeds. I think this assumption is fundamentally flawed."

Fully agree.
Robert Sayre
Wednesday, 08 February 2006 13:39:33 (GMT Standard Time, UTC+00:00)
"No support for application specific feeds." - maybe supporting root named feed trees that are isolated from the "public tree" would be better. I can see a point down the road where an application might want a private feed tree, maybe protected by a password, or possibly encrypted if the feed content is some sort of internal company feed brought down through a company intranet over a VPN. But overall a new feed tree or branch should be by default accessible to other applications.

The whole api seems to be missing some form of Search - is the feed store available as a directory structure someplace? Can Windows Desktop Search access it? If I were going to develop an application I'm going to want search, and to support it natively in my application I pretty much am going to have to keep a local copy of the feed data or at least a large index of some sort. Since we already have excellent search technology in windows with WDS, it'd be nice to see this built in.

"Support for obtaining XML elements which aren't supported by the API." - absolutly, Dare, Bandit does an excellent job of providing this. The MS feed platform folks should take a look at your implementation.

"No ability to append application specific metadata to feeds." - 100% agreed again.
Jim
Comments are closed.