Paul Dix Explains Nothing

Feedzirra gets a few more features

Feedzirra, the best feed parsing library on teh intarwebs, just got a little bit better thanks to the help of a bunch of different people. I think this release really highlights the power of Github. OSS has always been about distributed development, but with the hub it has become effortless. I can't imagine this happening on a regular old CVS or SVN site.

Here are the details on what's new:

• Gzip and Deflate support added thanks to Ozgor. Now in addition to speed, you'll save even more bandwidth. I updated his change to request gzip and deflate by default on all feeds.
• Support for categories on entries thanks to Jeff Chupp.
• Bug fixes from Jed Hurt and Greg Borenstein.
• I've changed RSS & RDF parsing to use the same class. I'm considering just combining the FeedzirraAtom and Atom classes into one as well. Thoughts?
• Based on feedback from my post last week about the sanitize api using proxy objects, I've changed sanitization up. I started with the code from James Adam's response and added a little bit. I'll probably modify it later by just opening up the String class, but the API will keep its new form. Here it is:

# sanitizing an entry's content
entry.title.sanitize # => returns the title with harmful stuff escaped
entry.author.sanitize # => returns the author with harmful stuff escaped
entry.content.sanitize # => returns the content with harmful stuff escaped
entry.content.sanitize! # => returns content with harmful stuff escaped and replaces original (also exists for author and title)
entry.sanitize!   # => sanitizes the entry's title, author, and content in place (as in, it changes the value to clean versions)
feed.sanitize_entries! # => sanitizes all entries in place

I was hoping to get the Rails mapping and generator in this release, but I didn't want to wait any longer (maybe next week). If you're having any problems or have feature requests, please join in the Feedzirra discussion group.

Using a Proxy Object to Design an API

A feature I recently added to my Ruby feed fetching and parsing library, Feedzirra, is a call to sanitize the html in feed entries to protect from cross site scripting attacks. Adding the functionality was simple because of Dryopteris, a library written by Mike Dalessio and Bryan Helmkamp. The only thing left to decide was what I wanted to API to look like.

I settled on an odd pattern that I haven't used before and I offer it up here for your review. It was inspired by how the named_scope functionality in ActiveRecord works. I have no idea what you call this, so I refer to it in the title of this post as a proxy object. (here's a gist of my proxy object example for nicer reading)

# Let's say we have a feed entry object
entry = feed.entries.first

# now I could provide access to sanitization a few ways
sanitized_content = Feedzirra::Feed.sanitize(entry.content)
# but that's verbose and ugly, so maybe I could do this
sanitized_content = entry.sanitized_content
# that looks better, but I still didn't like it for some reason.
# I could also do this
santitized_content = entry.sanitized(:title)
# and define the sanitized method in entry like so
def sanitized(method)
  Dryopteris.sanitize(send(method))
end

# However, what I really wanted was something like this
sanitized_content = entry.sanitized.content
# I think this reads a little better

# Here's the code inside of entry that makes this possible
def sanitized
  dispatcher = Class.new do
    def initialize(entry)
      @entry = entry
    end
    
    def method_missing(method, *args)
      Dryopteris.sanitize(@entry.send(method))
    end
  end
  dispatcher.new(self)
end
# So in the sanitized method I'm creating a new proxy class
# on the fly. I'm redefining method_missing to send
# it to the method straight back to the entry.
# The last is an initialization of this proxy object that
# passes the entry itself in so it can have methods called against
# it later. So now I can also do
entry.sanitized.author
entry.sanitized.title

I'm still debating whether this is a good idea or just completely stupid. I think the API looks pretty clean, but it may just be confusing. Would I be better off just going with one of the first three examples? Would it be better to do something completely different?

Feedzirra - A Ruby feed library built for speed

For a long time I have been disappointed in the Atom and RSS libraries available in Ruby. I always had some small issue like it wouldn't normalize the way I wanted it to, it wouldn't grab feeds the way I wanted it to, or it was just plain slow. So I set about creating yet another Ruby feed parsing library. The result of this effort is Feedzirra: a feed (Atom and RSS) fetching and parsing library for Ruby.

One of the primary goals of Feedzirra is speed. I wanted it to be able to fetch and parse many feeds quickly. Examples with libraries that show getting a single feed are great, but I'm going to be using it to get thousands. With that in mind I spent time looking for the fastest way to parse feeds (nokogiri and libxml) and the fastest way to get feeds (taf2-curb and libcurl). I also built in logic for updating feeds that speeds things up even more, saves on bandwidth costs, and makes it dead simple to see what's new in an updated feed.

A second design consideration was that I wanted the library to be extensible and customizable. This means that you can add custom parsers to Feedzirra to handle different feed types (like microformats, for example). What this also means is that if you find a bug in the parsing on a specific feed, you can write a parser (should take less than 20 lines of code) and use it with Feedzirra while you wait for me or a contributor to get the bug fix in. Feedzirra also allows you to define callback behavior after success or failure of fetching a feed.

There are few missing things like support for gzip and deflate encoding and Ruby 1.9.1 testing, but all the basic pieces are there and the others are soon to follow. It's ready for use. For more information and benchmarks against other methods you can look at the readme for Feedzirra on Github. If you have comments on the API or if you find bugs on feeds in the wild, please comment in the Feedzirra discussion group. I'm eager to see this thing in use and want to make sure that it's rock solid. Special thanks to Pat Nakajima for looking at the code and helping to refactor a bit of it.

In the meantime, here's a gist to give you an idea of what Feedzirra can do and what the interface looks like.