An intro to routing and controllers.

I wrote recently about getting started with Merb. Yesterday, after having refer to my own post to remember how it all worked, I started on a new Merb app as part of the Great Grabb.it Rewrite of 2008. I very quickly ran into another area of Merb that’s a bit thin on documentation: Controllers. After some googling, some fiddling, and some brainstorming in the #merb irc channel I managed to figure out enough of the basics to get things up and running.

Right now, Merb’s sweet spot seems to be as an API server, which is exactly how we’re planning on using it. This usage means that while there might be a little bit of model integration for access control, most of the job is in routing URLs and data formatting. That means we’ll be spending most of our effort in config/router.rb and in our controllers. Specifically, we’ll need to know a lot about how Merb provides responses in various formats depending on the request url, i.e. it’s equivalent to Rails’ respond_to method. Let’s start by laying out our requirements and then I’ll show you how I translated them into Merbish.

For this app, I needed to take URLs within a namespace and route them to a single controller setting various params based on the rest of the request path. In other words, I wanted to provide URLs like:

http://myapp.com/music/artist.jspf

and



where the first url would give you a playlist of all of an artist’s tracks in JSPF (Javascript Shareable Playlist Format) and the second would provide an mp3 of the song with the given title by the given artist.

So, the first thing I needed was a series of routes that would recognize all URLS starting with /music and then grab the path after the first slash into an :artist param and the path after the second slash into a :title param. Finally, it would need to look for a format after the dot and pass that through as well if available.

It turns out the best way to do this in Merb is with nested routes, thusly (inside of the Merb::Router.prepare block in config/router.rb):

r.match('/music') do |music|
music.match("/:artist.:format").to(:controller => 'music', :action => 'artist')
music.match("/:artist/:title.:format").to(:controller => 'music', :action => 'track')
end


This is pretty self explanatory if you’re familiar with Rails routes, though it is probably worth noting that an early version of this I tried which eschewed the nesting in favor of including the /music part of the path in each route separately seemed to have problems detecting the format correctly (though it is more than likely the cause was driver error on my part rather than anything that Merb might do differently in that situation). There’s pretty thorough documentation on Merb routing if you need more specific help and that’s definitely not the case for the Controller APIs, so let’s tackle those right away.

Now, how do we consume those URLs in our application? We need a controller, thusly:

class Music < Application
provides :jspf
def track
display Track.new params[:artist], params[:title]
end
def artist
display Artist.new params[:artist]
end
end

There’s two main things going on here that distinguish Merb’s controllers from Rails’: the ‘provides’ class method and the ‘display’ method we’re calling in each action. These two methods work together to let us return our data in the right format on every request. And, while they might look confusingly different from the familiar Rails respond_to block at first, they turn out to make things much cleaner, eliminating the need to redeclare common formats over and over in each controller method.

So, here’s how it works: provides sets up a list of formats that we’re willing to consume and then display makes sure that we provide the right one for each request. When a request comes in ending in .jspf, display calls to_jspf on the object that gets passed to it (in this case new tracks and artists). If we wanted to provide javascript, xml, html, etc. we’d just add those symbols to provides’ arguments and then make sure the objects we passed to display could respond to to_xml, to_html, to_etc with the right data (there’s an additional option for html of using a template in the views directory that Merb can automatically detect; that case works just like Rails; also: html seems always to be installed as a format regardless of whether or not you pass :html to provides).

While this should be enough to get you up and running writing Merb controllers, there are a few other details worth noting. First of all, if you want to provide alternative formats besides, js, html, xml, and the usual suspects (like we do here with jspf), you’ll need to register a mime-type. We configured that by adding a single line to config/init.rb:

Merb.add_mime_type(:jspf, :to_jspf, %w[application/jspf+json])

There’s lots of other additional information about the request available to your controller actions as well, such as content_type. Secondly there’s other options besides display for returning content from your action. Calling “render” will attempt to automatically detect a template with the right format in the appropriate views directory. And you can always just render a raw string. Again, more details are available here.

There’s the beginnings of a great open source book being written by some folks on GitHub: Life On The Edge With Merb, DataMapper & RSpec.They’ve done a pretty solid job covering the basics of app initialization, modeling with the DataMapper ORM, and testing with RSpec so far, but their section on Controllers is blank so far. If someone wants to pick up the thin thread I’ve laid down here and run with it, that would be a great place for more documentation to accumulate.

Tagged: merb, ruby, router, controller

In the most recent On the Beat, Celia Hirschman advocates for the Musician’s Union to take a more active stand for musicians’ rights online. In a world where only 42% of internet users say they pay for music, she argues, the Union has a responsibility to advocate for musicians’ “right to be paid for their efforts anytime their music is played”. She notes the failure of legislative attempts to extract revenue for musicians from peer-to-peer file sharing, mp3 blogs, and CD burning and lays the blame at the feet of the Union as the primary organization that represents musicians.

I agree with half of this argument. The Musician’s Union has been embarrassingly lax in fighting the real battles that matter for artists in the modern music distribution landscape. What has the Musician’s Union done to stop the labels from cheating artists out of revenue from iTunes downloads? How about to stop them wasting their shrinking budgets on glamorous perks and inflated short-run corporate profits rather than developing new artists with the possibility of long and successful careers? Or what about to force them to hire people who can figure out new business models that fit the new technology?

None of these battles receive the slightest mention in Hirscman’s critique of the Union. She ignores the losses artists have suffered by being forced into vastly inequitable relationships with labels and instead highlights the ways in which the industry has failed to fully extract revenue from new forms of music consumption and fandom.

This wrong-headed focus on enforcement over transformation is symptomatic of the problems plaguing the record industry as a whole. Hirschman’s catalogue of Union failings closely resembles a punchlist of RIAA complaints and talking points. Focusing on missed revenue from new forms of fandom while the music industry’s entire distribution and profit model sinks into irrelevance is like getting upset over a spilled glass of champagne on the deck of the Titanic.

This mistake derives directly from the principle that Hirschman articulates in the piece: that artists “have the right to be paid for their efforts anytime their music is played.” This same idea was proposed recently by Peter Kirn at Create Digital Music:

Recorded music has value to consumers. And, in business, if something has value somewhere, it’s a business.

This is a core principle of the industry’s thinking right now and it is obviously, palpably false. In middle school, when a friend played me Sebadoh off of a walkman that he’d smuggled to school, transforming me in a single moment into a lifelong fan of indie rock, was that “theft”? Should Sebadoh have gotten paid?
When I worked at a local patisserie I used to play my favorite CDs throughout my shifts and would often write the band names and album titles down for intrigued customers. Should the shop have had to track and regulate everything we played so they could pay royalties to the artists?

This last is something of a trick question since enforcement of this kind of public performance royalty is something for which Hirschman specifically lauds rights-enforcers like ASCAP:

If you walk into a restaurant, nightclub or boutique and hear music playing, chances are very good a performance-rights organization have demanded compensation. These rights societies literally go door-to-door to insure their members get paid for music

Hirschman could not have this issue more wrong. ASCAP contacted the patisserie while I worked there saying they’d observed us playing music controlled by their members and we had to either cut it out, sign up for a very expensive pay service they were offering, or face a lawsuit. The business owners felt like they’d been shaken down by the mafia. Their response was to stop playing ASCAP music altogether and instead to put together a library of local music which we had explicit permission from the artists to play without royalties. Maintaining this library was a lot of work and we rapidly fell back into the old system of playing whatever we wanted, including ASCAP music, without permission, but now in an environment of greater fear and resentment. I would bet that a similar story holds for most places you actually visit beyond corporate chains: if you walk in and hear good music playing it is either local or in explicit defiance of an ASCAP threat.

And this story is a parable of what’s wrong with focusing on enforcement. Enforcement alienates consumers and tastemakers. It tarnishes the reputations of artists and the organizations that should represent them. It forces natural music consumption and sharing patterns underground. Possibly worst, enforcement distracts artists and the industry itself from solving the huge existential issues that they face.

There is one piece of information from Hirschman’s piece, however, that does hold out hope for the music industry if they do ever overcome these distractions and decide to face the real challenge of transformation: 42% of internet users pay for music. That’s an enormous number. How many internet users pay for news? Or search? Or social networks? I don’t hear anyone in these businesses complaining that their industry is in decline. That’s an enormous number and it reflects the incredible amount of passion that exists for music online. If the industry can’t find a way to transform that passion into a functional profitable business, it won’t be because because the users outfoxed their enforcements efforts. They’ll have only themselves to blame.

Tagged: music, industry, on the beat, Celia Hirschman, kcrw, enforcement, piracy, riaa

The relevant session for Grabb.it, the session that brought Chris and me the 600 miles down to the bay covered compliance with everyone’s favorite federal law, 17 USC 512, the Digital Millennium Copyright Act. Hosted by Colette Vogele, the founder of Vogele and Associates, Jonathan Band, and EFF Senior Staff Atorney, Fred von Lohman, the session covered all the major issues around the DMCA including explaining each of the four scenarios that have to be in place in order for it to apply — the so-called ‘safe harbor’ conditions — as well as the procedures involved with receiving takedown notices and how to respect user rights in the process (See my notes on the session for all the gritty details).

Beyond getting to pick the brain of Fred von Lohman (council for the defense in MGM v. Grokster and one of the two or three foremost experts in American copyright law) about Grabb.it for ten minutes, the best thing I took away from the session was a real understanding of the functional purpose of the DMCA takedown process.

Before the DMCA, copyright holders discovering infringement online had basically no legal recourse other than suing the site hosting the infringing content. Now, the DMCA provides for an intermediate action: issuing a takedown notice.

Say MGM discovers a clip from one of their movies on YouTube. They send an official takedown notice to Google who removes the clip and makes note of the event on the account of the user who uploaded it (purging repeat infringers is required to ensure continued DMCA coverage). Google also informs the user of the action and offers them a chance to issue a counter claim if they believe MGM acted in error or their upload is covered by Fair Use doctrine or some other copyright exception.

This process allows the hosting site to act as an intermediary between the copyright holder and the user — the two parties between whom the conflict actually exists — rather than having to absorb the full wrath of the copyright holder themselves when it should rightfully be aimed at the uploading user. The copyright holder gets their content removed from the web and the site owner can continue to operate without having to deal with crippling, expensive, time-wasting lawsuits. Of course, if the copyright holder is not satisfied with the process for whatever reason (for example if they object to the very existence of the site itself, like Viacom seems to do with YouTube), they can still sue. But, in most cases they can get what they want with a lot less cost and effort.

Rather than worrying about the Doctorow-ish pound-your-fist-on-the-table gross inequities that the DMCA might bring to national and international information and technical policy, this perspective lets us focus on the concrete dangers and opportunities it presents for our business — the things we can do to make it easier for copyright holders not to sue us and the ways in which we can help users do what they want while staying within the confines of the law.

Thanks to the EFF what was previously a source of confusion and fear for us is now one of operational confidence and new strategic ideas. Quite a lot to get out of a one day session!

Tagged: eff, dmca, copyright, compliance, takedown