ServerBrowserAppDevelopment

This page is in response to an exchange with Quim on the maemo-developers mailing list as part of the "Features to improve the platform" thread.

The ideas on this page translate back to a number of Maemo enhancements, bug fixes, and ideas that are not isolated to a specific area.

One means of developing sophisticated applications on the Maemo platform, or any platform, is to use a web page as the user-interface and a web server as the application engine. For example, the MIT Museum Without Walls project has built a Python web server using BaseHTTPServer containing the application logic and Javascript based web pages as the UI.

This methodology carries with it a number of inherent advantages:

  • Only scripting languages are used (Python, Javascript, HTML). There is no need to have access to compilers or other SDK's
  • Web browsers are extensively used in very demanding situations and tend to be fairly bug-free. By using the browser as the windowing environment, controlled by HTML and Javascript, the developer is freed from dealing with an entire class of UI bugs.
  • The applications can be developed and debugged by using a remote web browser (e.g. Firefox on a Mac OS X system) that offers good support for HTML and Javascript debugging. The browser need only be pointed to the Maemo's on-board URL.
  • The application can be quite portable, depending on how it is tied into the special applications or APIs of the host (Maemo) OS. The Python web server will run on pretty much any platform.

The methodology is not limited to Python on the back end. As additional scripting languages are ported to the platform (e.g. Ruby), these will be equally suited towards this kind of development.

There are a number of issues, however, that have come up. These issues could be classified as "collateral damage" because they could arise from design decisions made to solve other problems.

  1. Offline Use To be able to successfully use these kinds of applications, it is imperative that the browser can access local web pages (i.e. http://localhost: or file:///) without needing to be connected to the Internet. The original IT2006 OS browser needed a connection, but there was a work-around (the so-called Dummy IAP) that provided relief. Under IT2007, it is currently impossible to use the stock browser in an offline mode. A bug report exists for this - 339

  2. Browser Standards To be able to develop these applications well, it is very important that the browser be (and remain) as standards-compliant as possible. An example of an issue is that the stock browser does not properly handle layering of IFRAME elements. A bug report exists for this - 1453

  3. Hideable/Malleable UI Another feature that is important is that the browser should provide an essentially blank slate in terms of any UI it imposes. It would even be good if the browser's own UI could be completely wrapped. Again, under IT2006, the browser UI could be hidden almost completely, but under IT2007, the browser will pop up a status bar anytime it senses it's loading page content. For AJAX applications that constantly load pages to access small bits of server functionality, this results in a large number of disconcerting interruptions to the user with little "Loading..." status messages.

Beyond what can be seen (at least from this perspective) as a step back in usefulness, there are a number of things that would be really useful for this development paradigm.

  1. Javascript Access to Hardware Events A javascript library that provides hardware button events and allows the code to reassign the actions of the buttons. In a device used (in our case) as a Museum guide, the user interface must be as clean and simple as possible. There can be no expectation that the user knows the intricacies of the Maemo UI, nor can we teach the user how to deal with the Maemo UI elements. Rather we must develop large, finger-pressable buttons. Asking a naive user, possibly with limited vision to find the little "X" in the upper right hand corner is too much.

  2. Everything Is A Server An ability to access more functionality in a "server mode". Currently we launch mplayer in the background via the Python "commands.command()" function to play video clips. This works ok, but it would be much nicer if there were a way to control the entire set of Maemo services from the application. Starting and stopping videos, audio files, the PDF viewer, etc. Perhaps the goal is to use the Dbus to do this, but then perhaps there needs to be better documentation of the Dbus interfaces of these resources.

My immediate need for these kinds of things is in the above-mentioned Museum Without Walls project. Our goal is to make all of our code available as open source. Our hope is that we ultimately provide others with the ability to use what we develop to provide location-aware information about any space they choose to do this for.

We are grateful to Nokia for the support they have given us so far!