This is a continuation of my last blog post.

This week is an interesting one not only because I got a chance to exercise my developer muscle but also able to put many social computing concepts into practice. This is the week where I can truly sense the Web 2.0 connection. O’Reily clearly stated in his article on Web 2.0 that part of what made up of Web 2.0 paradigm shift is the “Lightweight Programming Models”. This LWPM can burgeon in the Web 2.0 era much like HTML in the Web 1.0 age. Technologies such as RSS, XML, ATOM, REST, SOAP(?), AJAX and many more LWPM share the same virtue of simplicity as HTML while they all rely on the HTTP platform. This week’s exercise shed light on both the benefits and detriments of mashup programing paradigm. First and foremost, I think that mashup style of information aggregation certainly has its merits. It makes gathering diverse and relevant information simple and easy. In fact, sites such as yahoo pipes, iGoogle, PageFlakes, etc. are the prominent data aggregator platforms used by many without deep technological understanding of interworking of the underlying systems. The simplicity drives the adoption of these technologies that encourage more data providers to adopt these loosely-coupled connecters. However, it is also the downfall of the technologies because it is essentially a “pull” only model from the perspective of a data consumer. There are basically no feedback mechanism in place for the data provider to have any form of notification to ensure service availability and integrity. In other words, if the server went down the only way to find out is through HTTP status errors (404, 401 etc.). Or if the data schema is changed it will cause data format incompatibility issue with the client program. It is essentially a “use it at your own risk” tool and no contractual binding expected from both parties. All in all, I think that the flexibility offset the peculiar behaviour of these technologies. Understand that these technologies are soft technology by design and so it gives rooms for innovation. I put some thoughts into making RSS more reliable and a few ideas sprung up while I was building my mashup app … data caching and service pinging (periodically) for data/service availability would certainly help.

So back to the application design and why I select what technologies I have chosen for my mashup app. My selection was influenced by my factors: my understanding of the technologies, the goal of mashup app and certainly the implementation time. From the data aggregation perspective, I chose web syndication format (RSS/ATOM) over SOAP because RSS/ATOM is more lightweight and easier to program with for my purpose and it is easier to parse to boot. RSS/ATOM would be considered as the lowest common denominator among other comparable formats before marking the decision for which client programming model/platform. Had I chosen javascript or other third party data aggregator providers I would be better off to go with RSS/ATOM for that they are more script-friendly and wider support overall. However, this advantage kind of goes out the window the moment I chose Silverlight as the client technology. Because Silverlight is .net based so it is OOP rather scripting oriented. The benefits for this are twofold: Higher level of interoperability and control with the added benefits of Rich Client Application features. Silverlight can be seen as the Microsoft version of Adobe Flash and they both fall under the Rich Client Application category that runs on top of a proprietary engine within a browser environment. It has the benefits of a more dynamic behaviour for UI than even ajax and the structural programming model (.net/c#) is more maintainable then javascript. For example, some server api is simply too difficult to program with a scripting language or even not supported. Consider twitter api which requires OAuth (http://dev.twitter.com/pages/oauth_faq) (in my opinion it works very much like Kerberos). The authentication process requires username/passwords and the ability to cache security token for future communication. Scripting language will not be a good fit become of the more complex communication process as well as the sensitive information becomes easily visible.
In the end I did not go with the Twitter API but rather I went with Twitter Search API instead (http://search.twitter.com/api/) which is a RESTFul ATOM based architectural style format. It can be executed in the following format:

http://search.twitter.com/search.atom?q=<query>

In my case I needed geolocation information so I use this:

http://search.twitter.com/search.atom?geocode=40.757929%2C-73.985506%2C25km

Perhaps this is good time to explain the overall picture of what consists of my mashup app:

1. Silverlight – Used as my client technology with a screen to display aggregated information based on search keywords along with a map of related tweets.
2. Twitter Search API – A RESTFul ATOM based search for tweets related to a specific geolocation and key word. Results are in both tweet message and location. Location information can sometimes be free text such as Edmonton, AB or lat/lon such as 51.23, 121.34
3. Yahoo RSS Web Search – Similar to Twitter Search API for Yahoo Web Search (http://developer.yahoo.com/rss/) result in RSS format. I use this query format: http://search.yahooapis.com/WebSearchService/rss/webSearch.xml?appid=yahoosearchwebrss& query=keyword
4. Yahoo RSS Image Search – Same as Yahoo RSS Web Search but returns images related to key words. I use this query format: http://search.yahooapis.com/ImageSearchService/rss/imageSearch.xml?appid=yahoosearchimagerss&query=keyword
5. BING Geocode API – A SOAP based API for geocoding tweet location such as geocoding “Edmonton, AB, CANADA” to 53° 33' 0" N / 113° 30' 0" W so they can be plotted on the map.
The Silverlight application bring the data from the above data provider unite them under the same UI. I program the app in C# and host it under my personal site. You can find it at: http://www.dicksonlam.com/AU/COMP650/AU.Comp650.MashupAppTestPage.html

Dickson