Sven Haiges (SG): Who started Knopflerfish and how did it evolve?
Erik Wistrand (EW): Knopflerfish (KF) is a spin-off project from Gatespace, which was one of the founding members of the OSGi Alliance. When Gatespace separated into two directions (Gatespace Telematics and Gatespace Networks) in the summer of 2003, the Gatespace OSGi software was no longer the core focus of the company, although it remained an important tool. At that point in time the software had been in development since 1999.

To keep momentum on the OSGi framework, I started discussions with Christer Larsson (Gatespace Telematics) and Greg Baltzer (Gatespace Networks) on how to release the software in open source form. We rather quickly decided to go ahead in this direction, and most of the OSGi related source was signed over to the newly formed Knopflerfish non-profit organization. This software is now available for anyone with a BSD-style license.

As soon as this was decided, the work started to move the code (quite a lot of Java sources) to a form that was more easily distributed. That work, including moving the build system from Make to Ant and introducing a new graphical front end) was done in late 2003 when the first release was made public at knopflerfish.org. The initial release supported the OSGi R2 spec, but work started immediately to create an R3 compliant version. KF is OSGi R3 since spring 2004 and work on R4 is on the way.

During this time, quite a lot of new services have been added to the KF distribution, mostly communications-related as SOAP integration and work on the HTTP server. Generally, integration towards existing systems has been important and quite some work has been made to make the core framework run smoothly on different platforms.

SG: What is your personal motivation to maintain this project?
EW: I really think that OSGi is a very good platform for Java life-cycle management. So, it simply makes me happy to see OSGi used. Also, Knopflerfish is a cool name.

SG: How much "R3 compliant" is KF actually? Do you implement all Standard Services?
EW: R3 compliance is a very tricky term since it involves certification from OSGi itself, which can only be achieved by OSGi members. The exact code from KF has been R3 certified by Gatespace Telematics in their OSGi product Uniserv, which uses KF as core. But, formally, KF can only claim to be "designed to be R3 compliant".

KF implements all of the framework functionality specified by OSGi R3, as well as the following services: PackageAdmin, PermissionAdmin StartLevel, URL service, ServiceTracker, Log, HTTP, Configuration Manager, Device Manager, User Admin, Preferences, Position API, Measurement API, Metatype API and XML service.

So, yes, all standard services are implemented, with the exception of the initial provisioning service, which really can only be implemented by a service provider.

SG: What do you expect to be part of the upcoming release 4 of the OSGi Spec- how long will it take to implement it?
EW: First and foremost, the new core framework functionality. This is, after all, what OSGi is all about - life-cycle management. Depending on how OSGi itself decides to publish the R4 specs, this should be available in KF in the Spring of 2005. Then, there are a huge number of new service specifications, some of which are hard to implement without support from device manufacturers, like the services specified by the Mobile and Vehicle Expert groups. I expect this to be a continuous activity during 2005.

SG: Do you know of any commercial installations, where KF is used? In which areas is it used most?
EW: There are commercial installations, which unfortunately are not made public. But they range from embedded devices in network control management to presentation tools in consumer devices. In these cases the HTTP server seem to be popular for enabling remote control of a device. The framework itself is used as a small-footprint deployment tool. KF is also used as basis for research projects in at least one mobile phone manufacturer.

In the research area, KF is mostly used for life-cycle management (the Jadabs project, for example). Several universities now use OSGi as basis for courses in distributed computation, and some of these also use KF. Those who do not use KF tend to use Oscar OSGi, which is also an Open Source OSGi implementation.

SG: What problems do you see regarding OSGi, and, is there any solution to it?
EW: There is a huge development problem originating from the OSGi Alliance itself, namely issues concerning the not-so-public process of the OSGi specification. This is only open for OSGi members (requiring quite a large fee), making it hard to follow the spec without the full resources of a company.

From my viewpoint this may slow down development, especially in the Open Source environment. It also affects the possibility of using the OSGI certification tools. Opening up this process would make development much easier. On the adoption side, there needs to be a clear usage model for the OSGi framework.

Currently, OSGi suffers from the too-generic-capability symptom. It's good for everything, so nobody thinks it's good for a specific usage. A few well-defined application areas could ease this, like the Eclipse adoption of OSGi has done on the desktop side, and which might possibly happen on the mobile device side.

SG: Where do you see OSGi in the next five years?
EW: As mentioned earlier, I see a few clearly defined usage areas being defined. Desktop usage is one such possibility. In a sense, OSGi is what JVM sharing should have been. Integration into the JVM itself would be the ultimate goal.

Further, the number of OSGi specified services would stabilize. Right now, I think there is too much duplication in the "standard services". Some of these will survive, some will not. There is a definite need for communication services between OSGi platforms, which I hope will appear during this period.

I don't think that OSGi will ever become a user-visible acronym, but as a deployment format and plugin mechanism it will quite likely be the core machinery of many Java-enabled devices.

Reference
Knopflerfish

Disclaimer: The views expressed in this interview reflect the personal opinions/experiences of the member interviewed and are not necessarily the views of JAXMagazine.