This recently appeared on the rssbandit-users mailing list

From: Dare Obasanjo <dareo@mi...>
Synchronizing RSS Bandit Across Multiple Machines  
2004-03-02 00:29
 Hello all, 
   One of the big features on TODO list is to implement a way to
 synchronize the state of RSS Bandit across multiple machines so that if
 you use it on one machine and start it up on another it remembers what
 you've read, what you're subscribed to, etc. I've gone as far as writing
 a spec[0] for a format that does this. The main problems I've had now is
 that there needs to be a server where the individual RSS Bandit
 instances can fetch feeds from in the same way your mail reader (e.g.
 Outlook) downloads mail from your mail server (e.g Exchange). Since it
 is unlikely that users will be able to setup servers for this purpose
 here are a couple of ideas I've thought of supporting. I'd love your
 feedback and added suggestions 
 1.) FTP support: This is straightforward, an RSS Bandit instance can
 upload and download a SIAM file containing synchronization information
 via FTP. 
 2.) Mail support: This is fairly crafty and some would call it a hack.
 RSS Bandit mails the subscription file either as a zipped attachment or
 as inline text content to the user's email address and can download it
 using POP3 if the user's mail server supports POP3. The appropriate mail
 to use for synchronization is identified by an extension header in the
 mail or some similar identifier. There are a large number of free POP3
 services[1] and users can create a throwaway account specificly for RSS
 Bandit synchronization. 
 Please all and you please none. 

If you are an RSS Bandit user I would appreciate your thoughts on the issue. Most of the responses I've gotten so far is that I should just implement synchronization support via FTP which I'm not sure is that accessible to the average RSS Bandit user.


Tuesday, March 2, 2004 4:51:06 PM (GMT Standard Time, UTC+00:00)
I agree, it won't be easy to provide such functionnality to the average user since it involves either setting up a file server somewhere, or configuring a plugin for the user's email software.

A solution that comes to mind would be to set up and maintain a public server (using a standard protocol or a custom one or a webservice) for that and make RSS Bandit use this public server for non power-users. I'm aware this would cause some maintenance issues, hosting fees, privacy issues, security issues but it would be damn easy to use and transparent.

Tuesday, March 2, 2004 5:14:03 PM (GMT Standard Time, UTC+00:00)
I would have thought it might be a good idea to abstract out the mechanism that is used to store and retrieve the file. This way, people could develop plug-ins to handle a variety of stores whether FTP, POP3, WebDAV, FPSE, XML storage system, etc. etc. Could even be as simple as saving a file to a USB key ring or whatever.
Tuesday, March 2, 2004 5:19:39 PM (GMT Standard Time, UTC+00:00)
I don't think synchronizing via FTP is too unreasonable. I think a lot of ISPs offer FTP, otherwise's content publishing via FTP wouldn't make much sense.

Personally, I like the idea of using a web service that could be a module to .TEXT and/or DasBlog would be nice.
Tuesday, March 2, 2004 6:11:35 PM (GMT Standard Time, UTC+00:00)
I use the current support for remote storage via FTP, and it works great. Having host the would be cool. Support from my own weblog is a nice idea too (i.e. extension for .Text)
Tuesday, March 2, 2004 6:14:05 PM (GMT Standard Time, UTC+00:00)
What's wrong with HTTP GET/PUT?
Julian Reschke
Tuesday, March 2, 2004 6:24:44 PM (GMT Standard Time, UTC+00:00)
I don't have the resources to host a public server nor do I want to deal with the security/privacy implications of hosting people's feed lists.

I've talked to the author of .TEXT and he hasn't seemed interested. I talked to the dasBlog authors a while ago and they showed some interest but I haven't followed up because I haven't been working on this actively. I don't know if either tool supports a plugin architecture where this functionality could be added.

None of my users have asked for HTTP GET or HTTP PUT support. FTP & File system storage are most frquently requested then some sort of XML Web Service support is also usually asked about. Secondly, I believe it is far less likely that the average person would have access to a server with HTTP GET & PUT support than it is that they'd have access to an FTP server.
Tuesday, March 2, 2004 6:44:18 PM (GMT Standard Time, UTC+00:00)
I agree with Haacked, most users are going to have ftp access. My provider has pretty clear instructions on using ftp with my account.
Tuesday, March 2, 2004 6:45:03 PM (GMT Standard Time, UTC+00:00)
I agree with Haacked, most users are going to have ftp access. My provider has pretty clear instructions on using ftp with my account.
Tuesday, March 2, 2004 6:57:47 PM (GMT Standard Time, UTC+00:00)
I second the plug-in idea!

Tuesday, March 2, 2004 7:14:54 PM (GMT Standard Time, UTC+00:00)

both IIS and Apache have GET/PUT support -- note that GET/PUT is already used for other similar problems like hosting shared calendars (Apple iCal/Mozilla Calendar).

Just a thought -- FTP on the other hand is not only oldfashioned but also has it's problems with firewalls.
Julian Reschke
Wednesday, March 3, 2004 6:46:03 AM (GMT Standard Time, UTC+00:00)
I'd like to see the following remote storage options:
1. IMAP - use a folder in the users remote IMAP folder structure to store data. It may also be possible to use IMAPS.
2. WebDav - Built into IIS and Apache and needs very little configuration to work and there are a lot of hosts on the net that supports WebDav. It is possible to use through both HTTP and HTTPS.
3. SSH/SCP - I don't like clear text transmissions.
4. FTP - At least an alternative, but its unsecure, and it is one of the few protocols still having problems getting through locked down firewalls with its ancient active/passive ftp/ftp-data communication protocol.

SMTP/POP3 is not a good solution in my opinion since it is easy for a user to have a misconfigured email client that downloads all emails instead of leaving them on server.
Wednesday, March 3, 2004 5:35:04 PM (GMT Standard Time, UTC+00:00)
I'm not sure, but I wonder if perhaps the "average" RSSBandit user actually _does_ have server access. I would very much like to request that support for more advanced, server-based solutions not be left out of consideration during your analysis. I think using a Sharepoint (as in Office 2003), an Exchange, or even a web service interface would be nice.

It might even be acceptable as a dasBlog (or .TEXT) extension much lke the OPML down/upload.

I know that just because you are a user of a blog client doesn't necessarily mean you are the owner of a blog server, but I think it might be a good idea to consider that this might very well be an opportunity for service providers.

I'd even say that FrontPage extensions (now called Sharepoint services?) are a better bet than FTP. In my travels, I'm noticing a lot more people blocking off FTP ports due to their inherent lack of security.

My .02.
Tuesday, March 9, 2004 12:20:47 AM (GMT Standard Time, UTC+00:00)
I have modified RSS Bandit so I can configure the folder used to store the application data. I then map a network drive on my server. When I'm on the internet I map the drive using WebDAV. I'm currently using RSSBandit from three different computers and it works like a charm. This is of course a hack, but without it I would not be able to use RSSBandit. I have no performance problems at all when I connect across the internet to my server sitting on a 2048/512 ADSL line. Only quirck is that all settings including window state etc. are saved so when I switch from my 1600*1200 desktop PC to my 768*1024 TabletPC funky stuff (like no visible window) may happen.

Here are some points to consider:

Security: FTP transmits the password in clear text. HTTPS or NTLM authentication are far more secure. Security (e.g. not having to transmit a password in clear text) is important for me. Creating a plug-in architecture for server synchronization seems like a very good idea.

Scheduling: Allow the user to control the scheduling of the synchronization. Manual synchronization is to tedious, but immediate synchronization as I'm using in my hacked RSS Bandit may be to demanding for some scenarios.

Locking: When several instances of RSS Bandit will synchronize data from a centralized store some simple locking or ownership mechanism has to be implemented. The user is of course not supposed to synchronize from several computers at the same time, but she may forget to close down the RSS Bandit instance running on her work computer before leaving and then later synchronize from home. This should be handled gracefully.

Information synchronized: OK, I'm lazy and havn't read the SIAM proposal, but I really hope that RSS Bandit will synchronize not only the blog list and the read/unread state of items, but also flags set on items.

Server synchronization complexity: Server synchronization could be a killer feature if you are a highly skilled computer user. E.g. you use several computers at different locations and understand that RSS Bandit information can be synchronized. So in my opinion there is nothing wrong in targeting this feature for these users. My highly subjective guess is that the current RSS Bandit user base in general understand the concepts of server synchronization. Really easy to use server synchronization for mom and dad and the boss probably requires central servers tightly integrated with RSS Bandit and stuff like that is probably better handled by commercial entrepreneurs and not an open source project.
Martin Liversage
Saturday, March 13, 2004 8:04:26 PM (GMT Standard Time, UTC+00:00)
I'd put my vote in for WebDAV. But, really, a framework that can deal with this is the way to go -- for example I have access to a few SSH/kerberos based servers. I access them via cygwin, and they are maintained be a professional support group. If I could, I'd write a plug in that would store the files up there... I've also given thought to useing the unix utility rsync.
Gordon Watts
Comments are closed.