public virtual MemoryStream

Greg and Simon are talking about an extension to BlogThis. I agree that BlogThis as-is is fairly limited and could definitely use some improvements. For instance, I had been considering writing a w.bloggar plugin but quickly realized that it needed a configuration setting (the install directory of w.bloggar). Unfortunately, IBlogThis does not provide any hooks for configuration of the plugin. Greg's proposal would fix this issue.

public interface IBlogThisEx : IBlogThis
{ 
    // Name of plug-in, suitable for display to a user 
    string DisplayName;  

    // Display configuration dialog to user, if applicable 
    void Configure(IWin32Window parent);

    // Return true if an editing GUI will be shown to the 
    // user when BlogItem is called. In this case, the 
    // aggregator will not display its own editing UI. 
    bool HasEditingGUI();
}

I do have some questions about this proposed implementation though:

• HasEditingGUI confuses me - if this returns false, the aggregator needs to display its own editing UI? But what should that be allowed to edit, and what should be passed to the plugin once editing is complete? One of the cool things about BlogThis (for me anyway) is that the aggregator does not need to include any kind of weblog-posting UI anymore, but instead can rely on the plugin to provide this if needed. Handling HasEditingGUI takes away this advantage by forcing aggregator-writers to now include an editor.
• I take it Configure() would be called by the aggregator from some kind of menu-option. Not all plugins will need to be configured though, so an extra boolean property hasConfiguration may be useful to inform the aggregator whether or not to show this menu-option.
• It would be nice if a plugin configuration would not need its own popup dialog, but can instead be integrated in the aggregator's existing configuration dialog (on a separate tab or something). To do this it would need to be passed a container-type parameter (Control.ControlCollection?) instead of a IWin32Window.
• If a plugin needs to be configured prior to use, the aggregator would need to have some way of finding out whether this configuration is complete. If the plugin has not been configured, the aggregator could either disable the "BlogThis" menu-item, or call the Configure() function first when "BlogThis" is selected.
• And finally, by inheriting IBlogThisEx from IBlogThis, you're breaking the Liskov Substitution Principle. Plugins that need prior configuration will not work in aggregators that only support IBlogThis as they will try to call IBlogThis.BlogItem() without allowing the user to first configure the plugin.
  Since IBlogThis is still new and therefore not many aggregators support it or plugins are written for it, we do still have the option of starting over with a new and improved version. It shouldn't be too hard to get the existing code-base upgraded to the new version.
  Oh and if we do this, we may want to follow Douglas' suggestion and call it IRssHandler instead. Plugins should be able to do more than just post to a weblog.