Building a Better Extensibility Model For RSS Bandit

0 comments suggest edit

Currently, the only plug-in model supported by RSS Bandit is the IBlogExtension interface. This is a very limited interface that allows developers to write a plug-in that adds a menu option to allow the user to manipulate a single feed item.

The ability to interact with the application from such a plug-in is very limited as the interface doesn’t define an interface to the application other than a handle. (For info on how to write an IBlogExtension plug-in, see this article.)

So last night I was thinking about an email that a user sent me. He wants to know how to add an intelligent module for filtering and classifying RSS feeds to RSS Bandit. This is for his thesis project.

Since that might not be a necessary feature for RSS Bandit at this point, I suggested that he implement it in a private build. RSS Bandit is open source and he can easily obtain the source code. But it occurred to me that there are hundreds of feature requests like this that have the potential to be great solutions in the future, but would be best implemented as a plug-in in the near term.

So as I sat there thinking about it, Torsten goes ahead and implements a prototype for it. Mind you, I hadn’t talked to Torsten nor Dare about this yet, but I’m sure it’s something we’ve all been thinking about. Especially as the number of feature requests continues to accumulate.

So what areas of extensibility might we want to support? Well there’s the callback on feed item download that Torsten implemented. That alone is quite useful. I can imagine building a plug-in that would score items based on how likely I’d want to see it or not. Thus it could sort items based on importance in a special feed. This would help with the increasingly large number of feeds I’m subscribed to.

Dare mentioned (and he’ll write more on this) the idea to support new data sources and formats. For example, it’d be interesting to build NNTP support as a plug-in.

I’d also like to build the ability to provide an interface for plug-in data storage. For example, suppose you build a plug-in that keeps statistics of your RSS feeds. You might want that stored with your settings so that when you synchronize RSS Bandit, your plug-in settings are synchronized as well.

]

Thinking far out there, perhaps adding the ability to support IE toolbars might be an option as I think some users actually use RSS Bandit as their primary browser.

The important thing is to design a nice interface to expose the RSS Bandit application to the plug-ins. In tandem we need to prioritize these extensibility options by looking at current feature requests and thinking about how many of them could be implemented as plug-ins.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.

Comments

avatar

5 responses

  1. Avatar for torsten.rendelmann@gmx.net (To
    torsten.rendelmann@gmx.net (To March 4th, 2005

    There was also a request from a research project lead/member mailed to Dare some time ago about such things. So the layer I prototyped matches exactly the needs you described on our abstracted newsitem and feed level no matter where the content comes from. And as I wrote it I tried to reduce the risk level tweaking Bandit the bad way by not offering too much of the internals (only some set properties on the newsitem/feeddetails level that makes sense to modify). Open the whole app as a programmable public exposed object model like Excel/Word is much harder than that simple plugin structure. So I think we now have a good starting point to try and go on for Nightcrawler. <br />Overall: exactly the thoughts I had today as I started to wrote... <br />BTW: all the new sources are checked in sou you can have a look, but they are disabled for the next release.<br /><br />TorstenR

  2. Avatar for Jon Galloway
    Jon Galloway March 4th, 2005

    Very interesting. I'm enjoying the recent trend from automation / scripting to interface driven plugins and provider models.



    I'd love it if the plug-in data storage could completely replace the xml filebased storage system rather than just add to it. The filebased approach seems too slow and resource intensive with thousands of feeds and entries. I'd started writing my own RSS Aggregator that runs off a SQLLite database for just that reason.

  3. Avatar for Jeremy Brayton
    Jeremy Brayton March 4th, 2005

    Sweet, I'm all for this in the next release (Wolverine). If you can get this out of the way now it'll have a better payoff later as you find weaknesses in the API. You'll also get a number of people trying to break the application from a plugin so there'll need to be a bit of policing to make sure everyone's playing nice on the playground. Right now there's very little plugin support so you can get away with a lot more than if you had a ton of developers using RSS Bandit as a platform (which it very well could easily become).



    I would personally take this as a sign that it's something RSS Bandit has been needing. If both you and Torsten both think about this at the same time, something strange is in the air. If Dare chimed in without speaking to either of you, that would have made for a freakishly weird story

  4. Avatar for Jeremy Brayton
    Jeremy Brayton March 4th, 2005

    The goal of the data storage should be an API that exposes potentially any medium. The main problem with the XML file approach is an XML file is text. If you look at your cache items, there can be upwards of many megs of text files. XML has to parse the entire file too, so much of the "problem" is simply that you're parsing an entire file for probably 2 bytes of data.



    Having most of the information stored in a SQL database where you just have to read rows would be a little more ideal. You wouldn't have to parse entire files, but specific rows. Hell with properly constructed SQL your cached information wouldn't be parsed in it's entirety. You'd just see the latest chunks you need.



    You could probably solve much of the XML problem by splitting up the cache into what's necessary vs. what's actually cached data. Separating the read and unread items into different cache files would be a step up. This way when you get new items to the feed, you're parsing a small subset of the entire cache. If you still want to view every post you can but it'll take more time because of the nature of what's being cached. By doing this, you may introduce an even greater performance hit so it'd be difficult to tell if this is beneficial over the current method. Having an indexing system might not hurt for what can be indexed as well, so you're hitting those cache files less.



    A SQL backend would handle much of this but it's difficult to handle a SQL database with an application. The best way to handle SQL would be to define the database schema and let the client (me) choose which RDBMS to implement. I could use the existing MSDE/SQLLite/MySQL installer or I could use my own database platform and plug RSS Bandit into it. I would just have to implement my own DataAdapter plugin to make it connect to the backend of my choice.

  5. Avatar for haacked
    haacked March 4th, 2005

    One thing we should consider (and I posted this in Torsten's blog) is creating a separate class-library specifically for plugin interfaces. We wouldn't want to force developers to reference NewsComponents.dll just to create a plug-in.



    As for abstracting the data storage, I think that is something Dare's thought about. We should see him post his thoughts soon.