OSGi and the User Interface

A problem I have been working on last week with a friend is the user interface (UI) for an embedded device (he actually works on providing personalized health information, but the problems are very similar). We did not start this field, the problem has been bugging the different expert groups since the OSGi began in 1998. Tom Idermark from Ericsson and I once wrote RFP 8 for “Client Access”. I even developed a prototype on an OSGi Release 1 framework. The RFP is now 7 years old but still reads as if it was written yesterday.

So what is the problem? In an OSGi device, the UI must be adaptive to many influences: The available services, the end users, the output device, the state. At the same time the UI must run on a device severely constrained in memory and CPU cycles, not an easy problem.

This is hard, and I mean really hard. The main reason why it is so hard is that the user interface is a highly valued piece of real estate; the user identifies all the services with what it will see on the screen. Being a good citizen and seamlessly blending your bundle in the generic UI does not always improves your relationship with the marketing department. Telling them that the logo is a bit warped because the generic version did not map well to the hardware is likely to make enemies for life; only Microsoft gets away with warped logos.

Still, from a usability point of view it is important that we find a (non exclusive) solution to the OSGi UI problem. Such an OSGi UI should address the following concerns:

• Bundles should be able to provide information, receive information, as well as notify the end user(s).


• Securely accessible local and remote


• Must be able to look very good


• The style should be consistent on a device, without requiring the bundles to be intricately aware of that style


• The end user(s) must be able to control the UI, if applicable

Web based UIs have an advantage here because they can be accessed remotely and locally, they can offload some processing to the client, today’s HTML can be used to build very rich UIs, and there is a lot of experience. The key problem is the portability of the different web techniques. Last week I was again confronted with the surprising variations browsers display in their Javascript and HTML implementations. The OSGi specifications supports Servlets, objects that generate web content, usually HTML. Servlets have the disadvantage that they want to control a complete page, it is very hard to merge the output of multiple servlets into a single page.

Portals are software frameworks that address some of these issues. The JSR 168, which is implemented in the Apache Pluto project, addresses some of the issues. Portlets are like servlets but deliver a fragment instead of a whole page. The Portal container merges different Portlets onto a single page.

However, Portals are really oriented to heavy weight computing and not applicable for smaller devices. The Portlets approach to the site style is too lightweight; it only defines a few Cascading Style Sheet classes for this purpose. Interestingly, Google has analyzed 1 billion web pages for their HTML coding style and found a surprisingly small number of primitives. Supporting the top 20 primitives would go a long way. Kumanan Yogaratnam and Eddie Drake of Espial and Myrio proposed a solution in this direction last OSGi congress.

A significant disadvantage of HTML is that the content gets mixed with form. The alternative is XML, and I have very good experiences with bundles that provide XML instead of HTML. The required formatting, based on the output device, is then created with different or a combination of XSLT stylesheets.

I have no complete solution but it looks like the parts are coming together to provide a more complete solution. Now we only have to find a group of companies that need this desperately so we can spec it!

     Peter Kriens
     OSGi Evangelist