Thursday, April 10, 2003 12:50 AM
RSS Aggregator Plugins
ScottW sent me an email about Simon Fell's suggestion for a common plugin model for .NET RSS Aggregators. I think having a common plugin model is a great idea and would love to implement something like this in SharpReader.
A few things about his proposed standard are puzzling me though:
- Why is the item-data passed around as XML? This seems like an unnecessary step to me as it means the aggregator (which should have already parsed the RSS XML by this time) will need to recreate an XML snippet, which the plugin will then need to parse into the individual fields again. I would think passing a
POJO regular .NET class would be a lot easier for both sides. The only downside I can see to that would be that future developments in the RSS standard may bring new fields, which when added to a class could cause incompatibilities between aggregators and plugins. Even something as simple as a Hashtable would be easier than XML though IMHO. When using standard RSS tags (like "title", "link", "description") as keys, this would be as easy to extend as XML, but a lot easier to create and consume.
- Is there a mechanism to support multiple plugins? Beside having a "BlogThis" plugin, people may want "EmailThis", "CopyThisToClipBoard", "SaveThisAsFile", etc. Each of these would need a separate name, keyboard shortcut, icon, etc. The aggregators would need to implement some way to override the shortcut though as it may already be in use.
- Just sending a <item>-snippet may not provide enough information - it could be useful if some feed-information is sent to the plugin as well (like rssUrl, htmlUrl, title, description, etc.)
- Dare comments that "ideally plugins should have access to the entire RSS aggregator as an object model". I agree this would be the ideal solution, but am afraid this may prove difficult to do in a standard way that works for multiple aggregators. After all, they all have their own unique features they may want to expose; how would that work in a common standard?
- Dare also comments that a discovery mechanism is needed. I agree. The easiest way to do this that I can think of would be to put a XML descriptor in the plugin-assembly with all the necessary information the aggregator would need to use it. Plugins can then be copied into a plugins directory from where an aggregator can discover them.
I will definitely be following the developments in this area closely. Some of the responses I have received from people about SharpReader is that they would love to be able to post to their weblogs from it. Implementing a standard plugin mechanism would be both more powerful and easier than building this functionality myself, so I'm all for it!
TrackBack URL for this entry: http://www.hutteman.com/scgi-bin/mt/mt-tb.cgi/31
re: items as XML vs. classes: please don't go the classes route. RSS (especially RSS 1.0) can have a lot more XML (or RDF/XML in the case of RSS 1.0) to it than just the most common elements. If anything, pass XML and provide a standard object which can be mounted on top of the XML to provide a property-based mapping of the common properties, but don't _solely_ pass objects.
re: multiple plugins and plugin discovery mechanisms - attributes and reflection are your friends.
re: item-snippet - agreed, but most of the example information you mention is already in the feed data. Information not already in the feed data (e.g. metadata about when the item was retrieved, when the feed was last checked, etc.) could be exposed through the object model.
re: the entire RSS aggregator as an object model (and this is the most important point of all) - The current number of .NET-based RSS aggregators is an indicator of wasted effort. Clean, widely-extensible object models can be complicated to design, especially with differing interests and opinions flying around, but perhaps an effort needs to be made to combine resources or at least collaborate more closely, similar to what has already taken place and continues to take place over on the RSS publishing side (eg. pingback, trackback, etc.).
Beware the dangers of over-generalisation. While a completely generic plugin format might be good for those other .NET aggregator developers so that they can benefit from your work - it may not benefit you.
I suggest that you develop the plugin framework in such a way as to provide easy-to-develop plugins with as much access to your application framework as you feel necessary - let other aggregator developers come up with their own plugin framework.