A few months ago Dave Winer posted the subscriptions harmonizer RFC which had the following problem statment and goals

Here's a new Web Service for people who use aggregators and have more than one computer. The problem: I subscribe to a feed at home but my aggregator at work doesn't know about it, and vice versa. This document is an RFC, and a roadmap for deployment.


1. The solution should work equally well for any aggregator. It should be possible, for example to use NetNewsWire on a Mac at home; Radio UserLand on a Windows machine at work; or AmphetaDesk on a Linux laptop. The subscriptions of each should be harmonized without the harmonizer knowing what app is talking to it.

2. It should rely as little as possible on the centralized component. I will operate a prototype service at Harvard, but it will be limited to 1000 users, and each user will only be able to harmonize 100 times per day. The protocol will be openly specified and clonable. I'm only trying to solve the technological problem, not the economic one.

I didn't like the proposed solution for a number of reasons, the main one being that it required a centralized server that was outside my control. However I had expected some adoption of this proposal by various aggregators and blogging tools but there wasn't much of a ripple caused by Dave's RFC. 

A few weeks ago Steve Tibbet launched a discussion on the RSS Bandit messageboard on subscriptions harmonizers. He also checked-in some code which I finally got around to reviewing and modifying today. The discussion revolved around how best to synchronize feeds in a way that gives users choice and flexibility. We settled on four approaches, three of which are currently checked in.

  1. BLOG STORAGE: Many users of news aggregators also have a blog which exposes APIs for remotely editing the blog using tools like w.bloggar. Also such blogs usually have a way to store and display a blogroll such as the one on the right hand side of my blog. Since this infrastructure already exists it makes sense for users to be able to use their blog as the host for uploading/downloading their feed list. In fact, the feed list on my blog was posted from RSS Bandit and there is currently code checked in that allows syncing of blogrolls with dasBlog. I interacted with my blog using this web service.

  2. SYNDIC8: During the discussion,  Bill Kearney who runs Syndic8 pointed out that there already exists hosting for blog rolls as well as an APIs for programmatically interacting with these blogrolls from the web. This is an example of blogroll on Syndic8. I was going to code the feature to enable syncing of blogrolls between RSS Bandit and Syndic8 this morning but the site was down.

  3. FTP: This is self-explanatory. One can use an FTP server as the sync location for uploading/downloading one's blogroll.

  4. UNC file path: Similarly self-explanatory. A network file share could also be the location of the synchronization point from the blogroll.

Below is a screenshot of the remote storage configuration tab.


  • Steve and I debated on whether the blogroll should be automatically synced with the remote site on startup and shutdown or whether this should be only done when directed by the user. Steve sees this feature as being akin to a mail server like Exchange and a client like Outlook in which case it should be automatic. I tend to avoid adding features to RSS Bandit that involve automatic downloading unless specified by the user. In all likelihood the compromise will be a flag that indicates whether syncing should be done automatically or not which will be off by default.


  • OPML which is the format used by aggregators for storing blogrolls is rather poor when it comes to storing the kind of state users would find useful in asynchronizing application. I for one am more interested in making sure that my aggregator at home can tell my aggregator at work which stories I've read so it doesn't mark items I saw at home as unread than I care about keeping the list of feeds I am subscribed to in sync.All this information is already stored in the file format used by RSS Bandit and it is unfortunate that users of news aggregators have to use a handicapped format like OPML instead. To make this feature useful it is likely that OPML either has to evolve or be replaced. Clemens Vasters, the lead developer of dasBlog, would prefer that I evolved the OPML I use by adding namespace based extensions for the information I deem pertinent (stories that have been read, refresh rate, etc) than creating a new format from scratch. I will start working on what this could look in the next few days and hopefully dasBlog & RSS Bandit will support these extensions in some way by next week.


Categories: RSS Bandit
Tracked by:
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=ff9afe59-735e-4934-b748-ef... [Pingback]
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=7ae505bc-fba5-43a9-b73e-13... [Pingback]
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=c5e678a4-7e74-4f13-bb68-57... [Pingback]
http://toxgxlv.net/ipod/sitemap1.html [Pingback]
http://silauma.info/dakota/sitemap1.html [Pingback]
http://weujmru.net/volunteers/sitemap1.html [Pingback]
http://otjjblj.net/04/index.html [Pingback]
http://weujmru.net/childcare/sitemap1.html [Pingback]
http://ukpuuq8.net/general/sitemap1.html [Pingback]
http://ptmy0sx.net/florida/sitemap1.html [Pingback]
http://lx2rnws.net/sublets/sitemap1.html [Pingback]
http://kf7ujzd.net/southwest/sitemap1.html [Pingback]
http://bombaylogger.web.aplus.net/00/index.html [Pingback]
http://harlleyd.extra.hu [Pingback]
http://ayavqoc.net/sitemap1.html [Pingback]
http://wg9eak4.net/sitemap1.html [Pingback]
http://tulanka.readyhosting.com/online/sitemap1.php [Pingback]
http://biggest-hosting10.com/~rocata/linux/index.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap4.html [Pingback]
http://host239.hostmonster.com/~blogford/sitemap2.html [Pingback]
http://gator413.hostgator.com/~digital/health/sitemap1.html [Pingback]
http://gator413.hostgator.com/~digital/wedding/sitemap1.html [Pingback]
http://fwve5e4.net/imdb/sitemap1.php [Pingback]
http://vahq8px.net/games/sitemap1.html [Pingback]
http://jz0uott.net/dining/index.html [Pingback]
http://gh9kwkn.net/comcast/sitemap1.php [Pingback]
http://cj6pvrd.net/household/sitemap1.html [Pingback]
http://cj6pvrd.net/creative/sitemap1.html [Pingback]
http://box432.bluehost.com/~zbloginf/sitemap1.html [Pingback]
http://box432.bluehost.com/~zbloginf/sitemap2.html [Pingback]
http://gator442.hostgator.com/~hockteam/alabama/sitemap1.html [Pingback]
http://gator442.hostgator.com/~hockteam/arizona/sitemap1.html [Pingback]

Tuesday, October 21, 2003 6:02:04 PM (GMT Daylight Time, UTC+01:00)
Aggie and AmphetaDesk both store hash's of seen items in the opml file, that ought to be enough to sync read items.

BTW, i tried posting this through the commentAPI, but it didn't appear.
Wednesday, October 22, 2003 12:36:58 AM (GMT Daylight Time, UTC+01:00)
Just a background reference at this point. I discussed a URL-based approach in "Subharmonization", http://bitsko.slc.ut.us/blog/2003/07/02/sub-harmonization .
Wednesday, October 22, 2003 8:26:28 PM (GMT Daylight Time, UTC+01:00)
I'm posting my comment via the CommentAPI so it should work. I looked at Aggie's OPML and it seems to save an MD5 checksum of some sort of the last item seen. I don't have AmphetaDesk on my machine so I can't check what it does.

I probably will lean towards embedding aspects of the RSS Bandit feed list format in an OPML outline, properly namespaced of course.
Thursday, October 23, 2003 4:30:40 PM (GMT Daylight Time, UTC+01:00)
This is definitely a feature that people will want, and it definitely looks like you're development is heading in the right directions.

If your interested, my thoughts on what you've said so far are as follows:

Having configurable transports for synchronization is a good thing. An even better thing is to have a flexible synchronization file format, as it is enevitable that you (or one of your developers) will want to provide 'added value' features that may not be supported by the 'standard' file formats, and in the same way, it is inevitable that some other aggregator developer will create their own file format, and you may want to support synchronizing with that format as well. Thus you may want NetNewsWirePro.sync* over FTP or AmphetaDeskPro.sync* over FTP, or either of these over some other protocol.

Sync on start up is definitly a desirable feature, and is also definitly a feature that you'll be wanting to make configurable.

*Yes, I made these up. But it might happen.
Comments are closed.