public virtual MemoryStream

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!