More REST and Web 2.0 for the Weekend

To many of us, loading up a few words like "Participation" or "AJAX" simply isn't enough to understand what embodies Web 2.0 vs. Web 1.0. The best description, ever, of Web 2.0 is What is Web 2.0 written by Tim O'Reilly.

Perhaps the best quote from the article is "Like many important concepts, Web 2.0 doesn't have a hard boundary, but rather, a gravitational core." O'Reilly then goes on to a meme map (Ok, if you feel foolish and don't know what a meme map is, you are not alone...maybe its Web 2.0 ;-), Wikipedia has a definition of Meme, I can only conclude that a meme map is really a me-me-map that has a map of me in the middle, as opposed to a Mimi Map, or a Mini-Me-Map). Still, the meme map is worth a look.

My friend Eric Olson and I collaborated (about 5 years ago) on a project that very much embodied the Web 2.0 characteristics, so I'm going to use it as an example since it was pre-AJAX and we won't get carried away with examples of Google, Flickr, and other off-the-shelf examples. I will present Stereo Beacon, then use O'Reilly's Web 2.0 "Patterns" to describe the 2.0-ness of Stereo Beacon as well as its weaknesses, thus hoping to illustrate the Web 2.0 patterns presented by O'Reilly.

First, a description of Stereo Beacon: Stereo Beacon is an MP3 player built with the Java Media Framework (JMF). But it wasn't a standard media player, it was fully networked, and fully peer to peer (without a centralized controller). As folks joined a channel, the metadata about their music (not the music itself) would be shared with all of people in the peer network. Anyone in the peer network could request that a song be played, regardless of the song location. The "requests" were queued up and people had votes that they could move a song up or down on the shared channel. As one song ended, a token would be passed to the machine that held the next song and that machine would kick off a multicast playing of the song (through JMF) that the entire peer network would hear in sync. Basically, a shared radio station based on music residing in each other's libraries. Because the files weren't passed around, we felt that we were helping protect digital content (though, there do appear to be rules governing the broadcast of music that could be applied here...still...).

I'll take some liberties with the implementation as I discuss Stereo Beacon and how it embodied Web 2.0 based on Tim O'Reilly's article. O'Reilly presents several principles or "patterns" that describe Web 2.0 characteristics. Stereo Beacon did not embody all of these, so let's talk about those it did:

  • Users add value: Simply put, the more users of Stereo Beacon, the larger your music library and the more variety you would have as users requested songs from each other's libraries. Also, you could use your votes with others to bump requests up or down the queue if you got annoyed at songs.
  • Network Effects by Default: Turn on Stereo Beacon, share your library, be included in the group. Stereo Beacon could also be used as a stand-alone MP3 player, a pretty good one too, but the goal was to start up and connect.
  • Some Rights Reserved: We could have done better, but the library format was easy to read and the passing of information could easily have been converted to a simple XML over HTTP format with simple REST-like resources identified (music library, song, etc...)
  • The Perpetual Beta: We were always tweaking builds and making new versions, had we had more users, the threading model could have been much better and we could have improved it substantially. Also, we didn't really push it out there or on our friends heavily...but when we did, bugs flowed in and we improved things. In addition to bugs, features were added and removed. With more users, this feedback cycle could have been much better with new versions being rapidly created based on the popularity of features (like voting or a "direct from CD" play mode that Eric added).
  • Cooperate, Don't Control: We never published our message framework, we weren't really asked to, but this would have been easy to do. Music players today could learn a lot from this lesson, media streams are incalcuably fun to hack, play with, and enhance.
  • Software Above the Level of a Single Device: As I mentioned earlier, the notion of "A user's music list" was not important to Stereo Beacon. The notion of the "Collective's" music library was paramount. The network blurred the lines between the individual, you had no notion of where your music was being played from, just that you had so much music at your fingertips for which you competed with others to build an anarchic yet similar radio station (late in the development of Stereo Beacon, we added the notion of channels so that someone's "Cure"-centric library wouldn't be mixed with someone else's "Dixie Chicks"-centric library).

Recalling that we were Web 2.0 before Web 2.0 existed, we did have some issues...we used a client-based graphics package that required an install. We weren't HTTP-based (we used socket-socket communications after we evaluated JINI/a still nascent JXTA/Jiro), and we didn't use XML heavily (remember, this was also just as the popular XML-standard interfaces were developing). Things we didn't do well were:

  • Enable the Long Tail: First off, it was probably a mistake to try to do pure peer to peer application programming. Its a fun experiment but, frankly, distributed thread models in a true peer-to-peer environment are hard. Had we went with a central-server model, we could have easily started to build out communities and enabled third-party add-ons based on our resource models and distribution models. This would have also allowed others to build communities based on our server and resource-sharing models, extending our tail outside of our own application box and into community models (of which few were available at the time).
  • Data is the Next Intel Inside: Our data was ripped purely from the MP3 IDV3 tags, then the channel was enhanced with voting information. Had we hosted the communities on our site, we could have easily built server-centric play lists based on the popularity of songs available in "neighboring" communities, thus creating our own extensions of the data and also increasing the Web 2.0 concept of "Users Add Value".

If I didn't have a couple of kids perpetually circling me in my off hours and Eric playing with alternate media streams (you would have to ask him...), the player could easily be rebuilt with substantial improvements in this brave-new Web 2.0 world, for example:

  • Web-based rather than client install: AJAX brings a level of interactivity we didn't have when we first built Stereo Beacon. This interactivity would have allowed a server-based model with little or no client install that simplified our threading models AND allowed us to extend the IDV3 tags with data collected in our community to create a better "Data is the Next Intel Inside". Also, making Stereo Beacon a Web-based Service and in Perpetual Beta rather than a client-installed Perpetual Beta would have allowed us to creep features in and out quickly and enhance them without making our users reinstall Stereo Beacon with each new build.
  • Standard Resource Models: The library formats were put together and single-minded, opening these up and offering our meta-data on the Web could have opened up unexpected community extensions. Also, using a REST architecture (XML over HTTP with message passing) would have allowed users to create add-ons and their own front ends and allowing us to host the "Data Inside" the application rather than controlling the application.

So, in a nutshell, read the Web 2.0 article by O'Reilly. Perhaps my FAVORITE of O'Reilly's patterns is: "Software Above the Level of a Single Device". Nicely done Mr. O'Reilly.


Post a Comment:
Comments are closed for this entry.



« July 2016