ecommerce content resolution

A few Playdar-related developments from Lucas Hrabovsky of Amie St (aka __lucas) —

He set up a page with song listings marked up using the hAudio microformat. hAudio allows code to know that one bit of text is the title of the song and another bit of text is the name of the performer. Here’s what his hAudio markup looks like:


            <div class="haudio">
               <img src="/static/assets/album-default-55w_55h.jpg" class="photo" />
               <div class="top">
               <span class="fn">Lucky Dutch</span> by 
               <span class="contributor">Radio Moscow</span>
               </div>
            </div>

Notice that nowhere in there is a direct link to an MP3. The labeled bits of text are fed to Playdar, which uses them to search the user’s MP3s (and other sources) for a song file with the same title and performer. If it finds one, it makes it available over an HTTP connection. In this format any in-browser player, like Quicktime, WMP, or a Flash player, can take over.

Amie Street is a web site that sells songs. If the user has one of their songs on their machine already, the content resolver will find it and make it available for playback in the browser. This mechanism enables web sites to play music without actually supplying it. No webcasting, no hosting, no transmission, no copying.

What if there is an MP3 on Amie Street’s servers that the user doesn’t have yet? __lucas wrote a content resolver plugin that does a lookup to Amie Street’s web API. If the lookup succeeds, the MP3 is made available from Amie Street’s server instead of the user’s local machine.

His code is available at http://gist.github.com/113795. It’s only 58 lines of dead simple PHP — the heavy lifting is all in the web service on the other end of the line.

For that to work with no further development the MP3 on Amie Street’s server has to be freely available. They’re really an ecommerce site, though, so what if they’re not giving the MP3 away but do have it available to purchase? That’s a frontier.


He and I got into a dialog about that frontier. I asked How does the ecommerce part work? I’m wondering about what the user flow would be when there needs to be an interruption to make a purchase. He proposed the following:

  1. Playdar should just nudge you that some of the items you’ve requested can’t be resolved (ie via a Tooltip).
  2. Click on tooltip to open review/login in jQuery.dialog
  3. Confirm purchase and kick off download
  4. The AS resolver could then stream you the full tracks while you wait for the download
  5. Once downloaded and scanned in, can now be resolved by playdar on it’s own for next tme
The Amie Street API could make this happen easily with a couple more additions.
The next step would be applying this to stores other than Amie Street. For example, you should be able to set a preference to go through emusic or automatically find the lowest price and go there. We need to make it as simple and convenient for people to buy [as possible].

So where things stand is that we’re on the cusp of ecommerce integration, a feature which would drive business at stores, enable users to access gigantic repositories on the fly, and allow interoperability between stores.

That said, automatically purchasing and downloading in a uniform way is a can of worms. It would be like the Amazon, eMusic, and iTunes MP3 downloaders, but in a single integrated form. Maybe the downloader can come with the resolver, so that each store supplies its own…