The Wolverine release of RSS Bandit has entered its final stretch; the bug count is under 15 from a high of over 50, the codebase is frozen except for critical fixes, and translations have started to trickle in. It is looking like the final version number for Wolverine will be v1.3.0.25 but don't quote me on that just yet.

Torsten and I have started talking about what we'd like to see in the following release, currently codenamed Nightcrawler. Over the next few weeks I'll be sharing some of our thoughts on where we'd like to see RSS Bandit go and eliciting feedback from our users. The first topic I have in mind is building a richer extensibility model. Torsten and Phil have discussed this issue in their blogs in the posts Fighting Ads and  Building a Better Extensibility Model For RSS Bandit respectively. As Phil wrote

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.)

Despite the limitations of IBlogExtension, it has led to some interesting plugins such as my plugin for posting links to del.icio.us from RSS Bandit.  This was actually a feature request which I fulfilled without the user having to wait for the next version of RSS Bandit. I'd like to be able to fulfill more complex feature requests without having users wait for the next version. Given the small number of IBlogExtension plugins I've seen come from our user base I'm pretty sure that it is quite likely that a richer plugin model would just end up mostly being used by Phil, Torsten and myself.  However I'd still like to get some feedback from our users about where they'd like to see more extensibility. Below are some of the extensibility points we've discussed along with usage scenarios and possible risks. I'd like to know which ones our users are interested in and would consider writing plugins with.

Feed Preprocessing

Plugins will be able to process RSS items just after they have been downloaded but before they are stored in RSS Bandit's in-memory and on-disk caches. This is basically what Torsten describes in his post Fighting Ads.

Use Case/Scenario: A user can write a plugin that assigns scores to news items according to the user's interests (e.g. a Bayesian filter) then annotates each news item with its score. For example, for me posts containing 'XML' or 'MSN Spaces' would be assigned a score of 5 while every other post could be assigned a score of 3. Then I could create a newspaper style that either grouped posts by their ranking or even filtered out posts that didn't have a certain score.

Another potential use case is pre-processing each news item to filter out ads as Torsten did in his example.  

Risks: My main concern with this approach is that badly written plugins could harm cause problems with the normal functioning of RSS Bandit. For example, if a plugin got stuck in an infinite loop it could hang the entire application since we'd never get back news items from the pre-processing step. Given that this is an instance of the halting problem I know we can't solve it in a general way so I may just have to acept the risks.

Pluggable protocols

Every once in a while, users ask for RSS Bandit to support other data formats and protocols than just RSS & Atom over HTTP. For example, I'd like us to support USENET newsgroups while I've seen a couple of requests that we should be able to support subscribing to POP3 mail boxes.

Ideally here we'd have a plugn infrastructure that allowed one to plugin both the parser and the protocol handler for a given format. The plugin would also specify the URI scheme used by the newly supported format so that RSS Bandit would know to dispatch requests using that plugin

Use Case/Scenario: In the case of USENET support the user would provide a plugin that knew how to parse messages in the RFC 822 format and how to fetch messages using NNTP. The USENET plugin would also register itself as the handler for the nntp and news URI schemes. The user could then subscribe to newsgroups by specifying a URL such as news://news.microsoft.com/microsoft.public.xml in the new feed dialog.  

Risks: Same as with Feed Preprocessing.

Hosted Winforms Applications

A user could add a .NET Winforms application  to RSS Bandit. This application would appear as a tab within the main Window and all its functionality could be used from RSS Bandit. There would also be some hooks for the application to register itself within the RSS Bandit main menu as well as mechanisms to pass information back and forth between the hosted application and RSS Bandit.

Use Case/Scenario: One would be able to host blog posting clients such as IMHO in RSS Bandit. The blog client would be distributed and updated independently of RSS Bandit.

Risks: This would be a great deal of work for questionable pay off.

Pluggable Storage

RSS Bandit currently caches feeds as RSS files on disk, specifically at the location C:\Documents and Settings\[username]\Application Data\RssBandit\Cache. It should be possible to specify other data storage sources and formats such as a relational database or Atom feeds.

Use Case/Scenario: A user can write a plugin that stores all RSS Bandit's feeds in a local Access database so that data mining can be done on the data.

Another use case is writing them to disk but in a different format than RSS. For example, one could write them to disk using the format used by another application so that the user could use both applications but have them share a single feed cache.

Risks: The same as with Feed Preprocessing.


 

Sunday, March 6, 2005 3:06:25 PM (GMT Standard Time, UTC+00:00)
Re. pluggable protocols, you might get some ideas from Emacs Gnus' backend interface, http://www.gnus.org/manual/gnus_343.html#SEC343
Sunday, March 6, 2005 4:35:07 PM (GMT Standard Time, UTC+00:00)

I've always wanted to write a plugin that would allow me to write a custom parser for those feeds that don't include comments. I suppose that would fall under "Feed Preprocessing."
Ricky Dhatt
Monday, March 7, 2005 7:25:26 PM (GMT Standard Time, UTC+00:00)
RSS Bandit is the king here and all of the plugins are it's minions. In the halting scenario, it suggests that a plugin can somehow be considered king. This is done by elevating priveledges or by going into an infinite loop which makes the king work too hard to function normally.

RSS Bandit, as a good king, should constantly monitor the minions to make sure they're playing nicely with it. The king doesn't care how the minions play with each other but all requests to the king should follow a strict format. This is where the analogy of the palace guards come in. When a minion falls out of line, the guard throws them in jail, too many grievances and it may permanently sit until pardoned.

Outlook 2003 does this by disabling certain plugins that don't seem to be coded well and you have to specifically enabled them. This can get annoying to users but the application should monitor plugins to make sure they're doing what they should be. When you introduce rigid guidelines you somewhat limit the innovation that can happen by developers but sadly there does have to be a middle ground. You have to introduce rules otherwise you give the plugins too much power that will be used in the wrong hands, it's usually only a matter of time.


While we're on the subject of Use/Scenarios how about introducing a way of caching the commentRSS feeds? I could combine this with Feed preprocessing to have a "by conversation" view. I can use this to track comments I've made on other blogs and the responses to those comments. I wouldn't have to check back every day or so to see if someone responded. It's not a perfect scenario because some comments made by others won't be addressed to me but it will arrange them in the view so that it's a little easier to manage.

A cache for the comment feeds would be good simply to tell which comments have been read. I could also see you rebuilding an entire blog from using the cache in RSS Bandit. The only downside is that comments are usually removed frequently and while deleted posts are cool to keep in cache, deleted comments are not. There's probably better reasons why you decided to leave out caching the comments that I don't know about, but I just thought I'd throw that one out there.
Tuesday, March 8, 2005 8:47:44 AM (GMT Standard Time, UTC+00:00)
Hello,

'Pluggable Storage' is very nice.
I want to store RSS Cache to SQL Server Express.
It may became more search performance with Full-Text Search.
and, more extend use of cache with trigger, SQLCLR.

Regards,
Wednesday, March 9, 2005 3:51:16 AM (GMT Standard Time, UTC+00:00)
Re: Halting problem
There may be a solution by implementing a timeout on the caller side, although I'm not 100% sure how to do that ;-)
Saturday, March 4, 2006 11:07:29 AM (GMT Standard Time, UTC+00:00)
Than will be engaged today?
Saturday, March 4, 2006 2:52:52 PM (GMT Standard Time, UTC+00:00)
Hi! How to me to adjust a background of page?
Friday, March 10, 2006 1:32:51 AM (GMT Standard Time, UTC+00:00)
Greetings to all! Excuse for this message, but at you excellent design of a site! Very much it was pleasant to me, I shall come here very often!
Monday, March 13, 2006 4:08:43 PM (GMT Standard Time, UTC+00:00)
Very interesting and beautiful site. It is a lot of helpful information. Thanks!
Saturday, March 18, 2006 2:59:05 PM (GMT Standard Time, UTC+00:00)
Very interesting and beautiful site. It is a lot of helpful information. Thanks!
Saturday, March 18, 2006 7:38:18 PM (GMT Standard Time, UTC+00:00)
Very interesting and beautiful site. It is a lot of helpful information. Thanks!
Comments are closed.