Flow for pay per download integration

If ecommerce was integrated into Playdar, what would the user interface look like and what would be the system architecture?

You have Playdar on your own machine. You go to a web page. The page has a reference to a song and Javascript which knows how to interface that reference with the Playdar core on your machine.

The Javascript calls to the Playdar core to resolve the reference. The core calls your installed resolver plugins. The resolver for MP3s on your local machine is called first without success. The resolver for Amazon MP3 sales is called second. It finds a match in Amazon’s catalog. It then reports failure, because the song is not immediately available, but it also puts up a dialog box to ask the user whether to make the purchase.

If the user confirms the purchase, client side software performs the transaction. It charges the customer’s account, downloads the MP3, and installs the MP3 as needed, for example by adding it to the iTunes music library. Last, it posts a notification to the user about the outcome of the transaction.

If the time to play the song hasn’t passed, the resolver gets the information to the user’s player that the song is now available. How and when this happens is up to the user’s player, not the resolver or the Playdar core. For example, after a failure the player may continue to poll the resolvers with a timer set to an exponential backoff.

If the time to play the song has passed, the next time the user comes to that song the resolver will be able to render it.

---

This flow can support multiple stores with overlapping or non-overlapping content. For example, if EMI’s resolver sold Beatles MP3s and Sony’s resolver sold Michael Jackson MP3s, the user would be able to get both Beatles and Michael Jackson without there being any store that had deals with both.

---

Related mockups / prototypes from Lucas Hrabovsky of Amie Street:
http://beta.amiestreet.com/lab/whereshouldibuyit/#home
http://beta.amiestreet.com/lab/haudio.html