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
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!