Archive for the 'Google Reader' Category

Release of RSS Feed Reader, Newsline Pro

I’m doing a soft release of my new product, Newsline Pro. It’s an RSS reader, fetcher, and store-er thingie similar in concept to Google Reader. It stores full feeds (individual entries up to a year), and keeps track of read and favorite status. It has a responsive, Retina enabled web app so you can catch up on your feeds from any device.

Go to newslinepro.com to find out more and sign up for a free trial.

If you’re a developer, you can check out the Newsline server source code and the API documentation.

Just Say No to Hate, or at least the Google Reader API

Ever since Google announced that Reader was going away, there’s been a lot of speculation and commentary on what the next RSS Sync API should be like. Several people have suggested the best thing to do would be to implement the Google Reader API on top of another server, since it’s already in wide use. I think this is a fantastic idea, assuming you’re never going to write a RSS client or server ever again, or if you’re some sort of RSS Hitler or something.

The Reader API is only used because its is:

  1. free
  2. from Google

but mostly because of #1. It is not some sort of fantastic API. It was written by engineers whom, I assume, took massive bribes from the Atom Format Worldwide Dominance Consortium, Cabal, and Trade Expo. So existing clients aren’t using it because of its ease of use.

My secret project for the past few months has been writing an RSS server and client. The API has gone through some major revisions, and I’ve learned some valuable lessons through this exercise.

First, making an HTTP request in any modern programming environment is trivial. Also, parsing the JSON or XML response is likewise easy. The difficult part of writing a client is processing the results of an API call, and matching it up to the internal data model. If the server can segment up data such that it matches up with the client’s data model, that becomes a huge win for the client. Likewise, having a single server call that can return all of the data needed to fill one screen on the client can make things massively more efficient.

The wrinkle here is that different clients will have different needs. A web app won’t have much local storage available to it. A desktop app might want to fetch the feeds itself, but have the server manage syncing of the subscription and read status. The second big lesson I learned is trying to write exactly one API to fit all clients is impossible or at least horrendously inefficient. Which is why the Google Reader API probably sucks for everyone but Reader.

In the end, the user doesn’t care about the what API or APIs are used by the client. They just want all their clients to sync to the same server, but the method to do so is immaterial to them. Clients will want an API that is easy to use and efficient for their data model. Therefore, I’m suggesting that its not only OK, but beneficial for everyone, for a server to have multiple APIs, each tuned for various clients.

Let us throw off the tyranny of the Google Reader API! ¡Viva la Revolución!

Or whatever.