April 14, 2003
@ 12:58 AM
Comments [0]
BlogThis: How Not To Design An Extensible API
The reason I didn't like the original proposed interface was that it limited the scope of plugins. It basically said a plugin can do is react to an RSS item it has been passed. In RSS Bandit terms this means that the only place a plugin makes sense is when you right-click on an RSS item in the listview (screenshot). Granted there are a lot of cool plugins you could write with this such one that enabled printing of RSS items, one that opened the enabled you to forward the item as an email or one that enabled you to post a reply to the item to your blog. However none of these involve integration with the aggregator the plugin is interacting with. This is analogous to an Internet Explorer plugin only having access to the current HTML the web browser was displaying and not the browser's object model. The API is useful, limited but useful.

The second API is just a disaster waiting to happen. I've posted prior thoughts on the lessons we've learned on my team and across the CLR/BCL on the fragility of interfaces when it comes to versioning. Sam Ruby also points out to the proliferation of "2" and "Ex" suffixes in COM definitions that have been around a while. Specific to the API, here are my issues with Don's version which is SImon's version plus implementing IXPathNavigable as well in the RSS item.
  1. The most interesting parts of an RSS feed are not exposed by the interface. There is no way to tell the author of the post, the category the post is in or where to find the comments in response to the post. These are just a few of items from items from the RSS 2.0 namespace that are not supported. This interface also doesn't allow for supporting elements in the item from other namespaces which precludes things like supporting the CommentAPI or a number of the Dublin Core elements.

  2. Implementing IXPathNavigable on this interface seems to be pushing complexity on implementers with dubious benefits. It's unlikely that anyone will want to perform XPath queries or run XSLT transforms on an implementer of the IWeblogItem given that they can easily interact with the 5 properties in the object much quicker (both code and performance wise) than they can perform queries or stylesheet transformations. One suggestion for the justification of implementing IXPathNavigable may be that it allows the implementer to expose more info about the RSS item than those exposed by the properties of the interface. For example, this would mean that using an XPathNavigator over the IWeblogItem gives access to the dublin core elements and ither namespaced elements in the RSS item even though only five of these elements were directly accessible as properties via the interface. This is confusing in its duality but at least lends itself to extensibility. However, at this point one wonders why not just provide an XPathNavigator as the RSS item and not the paltry IWeblogItem interface.

  3. The interface does not expose enough information about the RSS item, goto (1) for more discussion about this.

 

Categories:

« RSS Bandit v1.1 beta, Ladder Theory of R... | Home | Tight Coupling vs. Loose Coupling »
Comments are closed.