Archive for June, 2009

Desktop Mashups: Closing the Gap Between the Web and the Desktop

June 9, 2009

Google and other web-centered businesses try to establish the web as a platform similar to an operating system. Many new web services use interactive GUIs to offer email clients, messaging, word processing and other services that are in their behavior similar to traditional desktop applications. Client-side scripting, well defined APIs, and asynchronous data exchange are the key elements of the interactive web interfaces that rapidly spread under the Web 2.0 label. Developers of mashups go even one step further and create new web applications by combining data from different sources. Numerous examples of excellent mashups show that the remix of data in mashups can have significant advantages compared to the individual web applications still providing the data. Unfortunately, the Web 2.0 has also some major disadvantages and creates new problems.

The most obvious technical risk of storing data on web servers or computer ‘clouds’ is the catastrophic failure of a web service that can create major problems especially when no backups or alternative programs exist. Besides such technical issues there are also very serious problems related to the code and the user’s data as Richard Stallman recently pointed out. He argued that the common business models of cloud computing get users over time into a trap of proprietary systems including the lose of control over their data, and paying eventually more than for an equivalent desktop application. Other unsolved issues include privacy and ownership questions related to user generated content. Stallman criticized also that the Javascript code of websites, although freely distributed, is in many cases so obfuscated and unreadable that it can not be considered to be Free Software.

A white paper published by MAYA Design questioned the technical reliability of the centralized cloud structures. The authors describe today’s cloud computing as “radical experiments to be performed by gigantic, non-redundant entities.” Their suggestion is that “until we understand a domain of endeavor very, very well, we should insist on decentralized, massively-parallel venues for dubious experiments. In the information economy, it means net equality, information liquidity and radically distributed services (and that’s pretty much the opposite of “cloud computing” as described today).” Also, they argue that short-term profits, and insufficient thinking about architecture, security, and resilience may guide developments in the wrong direction. Serious warnings about the risks of cloud computing come now even from more main stream journals such as The Economist saying that the economic advantages are associated with the customers’ risk of “losing control once again, in particular over their data, as they migrate into the cloud.” As a specific example they mention that it may be more difficult to change the service provider than migrating from one computer application to another: “For a foretaste of this problem, try moving your MySpace profile to Facebook without manually retyping everything.” Another report entitled “AppEngine doesn’t fit the needs of startups on the runway” described how limited data access made impossible to run a statistical analysis of the user data. Without the option to download the data buried in Google’s database the analysis has to run as a job on AppEngine but once the database grows bigger and the job takes longer it will hit AppEngine’s 5 second timeout and cannot be completed anymore.

The big challenges of keeping the freedom and independence from individual web services, and supporting the principles of free software on the web including full control over our data show that we need to develop alternatives to the risks of purely web-centric applications. We have to ask for example: Is it possible that we use mashups and other new developments of Web 2.0 without loosing the freedom to control our data and the application’s code? Mashups provide very interesting new concepts for integrating different applications. In fact, Google CEO Eric Schmidt expects that Web 3.0 will be “applications that are pieced together.” I agree that small scripts can be simple but powerful tools for redirecting and manipulating data on the web as well as on the desktop. This concept of integration has the potential to change our desktop paradigms. I first realized this when I started writing small Bash and Python scripts. However, I think the more important step was adding a tiny CGI server. This user-centered server running on my desktop allowed me to integrate both web services and desktop applications with some small but very efficient applications I needed.

Mashups require essentially only two things: 1) client-side or server-side processing, and, 2) proper APIs supporting efficient data exchange between client and server. Most mashups are relative small applications that improve usability by linking and remixing the data of more than one dedicated web application such as Google Maps, photo sharing, social bookmarking, social networking, web mail, and chatting. The data exchange among web applications is achieved by a simple old-fashioned text channel. In fact, this type of communication is very similar to the traditional data exchange between concatenated text processing tools in Linux/Unix, also referred to as pipes. The only important advantage of the text channel used for web applications is the standardized structure for sending data, e.g. “key1=value1&key2=value2”, and of character encoding for data to protect the control characters, e.g. equal sign. Unfortunately, these key concepts of web APIs that are essential for mashups are largely missing in our desktop applications.

The few programs with useful APIs that I know include Krunner and Korganizer both part of the Linux/KDE environment. Krunner has since KDE 4.2 an exciting new concept that allows not only starting programs similar to the command line interface (CLI) but shows also dynamic search results while the user is typing. Krunners numerous plugins include also calculations, searching for contacts, opening profiles, and other interesting links to different programs. Korganized includes both a GUI and a simple CLI for a calendar. The CLI allows to add, list, and delete calendar events. So, it can be used as API for scripting and data exchange with other applications. Most applications, however, do not support such data exchange although they would greatly benefit from higher integration at the desktop. Thunderbird, for example, would be much more useful if I would be able to place links in calendar event, ToDo items, notes, etc. pointing to specific emails with additional information. Ideally, Thunderbird would support both opening of the email and returning of their content for displaying it in a desktop mashup. Thunderbird would also benefit from a “command line” similar to Firefox’s URL supporting smart keywords and bookmarklets. Combining the desktop CGI server with Firefox’s smart keywords allowed me to send, receive, and remix data similar to mashups. Ubiquity on Firefox also promotes mashups and is a very interesting new concept except that without a mechanism like a CGI server it is unable to communicate with other desktop programs. I think an integrated solution for a CGI interface would promote integration with other desktop applications and mashups including the powerful ubiquity. It would allow us to develop very efficient user-centered desktop mashups that can basically integrate any desktop application that has a sufficient API. I think the common web standards for URLs provide an efficient and robust text channel for the exchange of structured data at the CLI level.

In summary, running a tiny CGI server on the desktop allows to build applications integrating different data very similar to mashups on the web. Developing such desktop mashups doesn’t mean that we need to abandon web applications but that we will have more freedom to choose and that we can integrate both desktop applications and web applications. I think the last point is especially important because it is a major limitation of web operating systems.