An update has been made to River4.js that enables it to write its data to a local file system as opposed to using Amazon S3. You may find that option preferable because it eliminates the complexity and cost of using S3. The addition of local file system support makes River4.js function nearly identical to the original River tool of the OPML Editor.

I've been using Dave Winer's River to manage the RSS subscriptions that I follow ever since Google Reader was killed. I choose to use Google Reader because it enabled me to read and manage my RSS subscriptions from any device connected to the Internet. Previously, I used apps that ran on my personal computer that restricted me to only reading my subscriptions on that computer, preventing me from doing so on my smartphones and tablets.

When Google announced it was turning Reader off, I looked around for a replacement. I initially thought I would use Feedly, but I also tested Dave's original river by setting up for myself an instance of the OPML Editor running on an EC2 image on Amazon following the EC2 For Poets instructions. I came to prefer the simplicity of the river format and didn't mind the cost of having a Windows server available to me on the Internet.

The point is that I have grown used to being able to read my RSS subscriptions using any smartphone, tablet, or computer, such that it is now a basic requirement, which brings me to the local file system change. I certainly see the cost and simplicity benefits, however I want to retain the ability to read my feeds anywhere.

To do so using local file system appears to require that I either have a web server running on the computer providing the local file system, or make the file system available on the Internet so that I could use the RiverBrowser to read in my feed files to that it can render them. From my point of view, adding a web server like Apache to my set up is adding complexity. Now I have to worry about maintaining that web server. The web hosting S3 provides is very convenient.

I am not entirely sure how to make the file system available to the Internet for RiverBrowser to access, one possible solution may be to sync a copy of the feed files RiverBrowser uses to a public folder on Dropbox, but then I would have the complexity of managing that synchronization.

It seems to me that the local file system support is most easily implemented on a local computer. I find that solution not as desirable as the hosted storage approach. Fortunately, local file system support is an addition so I can stick with S3 and use Heroku. If I want to eliminate Heroku from the mix, I could use the EC2 AMI image that Chris Dadswell is working on to host my own instances of node on Amazon so that I don't have the data transfer costs like what I have seen when using CloudAtCost to host River4.