Safe from the Losing Fight

I’m looking for beta testers for my RSS news reader. Right now the only client is a web app (mobile and retina ready) so that’s what you would be testing. If you are interested, email me: andy at fortunatebear dot com.

If you’ve followed this blog for any time you’re probably aware of my series of articles on how to implement boolean operations for vector graphics. As part of that series I created some sample code called VectorBoolean to demonstrate the principles.

If you used the sample code in one of your projects, you may have noticed it had several bugs of varying severity. Fortunately, I recently spent some time fixing many bugs, and adding enhancements to deal with some of the more complicated scenarios. You can find the most recent version in the BitBucket repo.

These fixes were possible due to the gracious funding of Mapdiva, makers of Artboard, which incidentally is using this new version of VectorBoolean. You might also recognize them as being the creators of DrawKit.

If you would like to use VectorBoolean but need some bug fixes or enhancements, I am willing to do them for a reasonable fee. If interested, email me at fortunatebear.com, with my first name as username. I don’t have immediate availability, and there’s already a queue, so please keep that in mind.

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.