Thursday, April 2, 2009

1,000 reasons to go for Mobile OSGi

Apple has recently announced the iPhone OS 3.0 Software. As for any of their public statements, once again Apple is extremely proud of its own achievements. The new OS version is said to come with 100 new features and an incredible set of 1,000 new APIs. Indeed, version 3.0 seems to mark a major milestone in the iPhone evolution and I am sure they really did a great job.

What’s the connect to OSGi, though? The iPhone 3G device was launched in June 2008. The new OS 3.0 is expected to be launched around mid 2009 - that's 1 year period at least. Apple claims that ...With the new SDK, members of the iPhone Developer Program can build applications that do even more... I'm sure they are not exaggerating on this. However, why would developers had to wait 1 full year (!) to get more APIs? Why to have them wait 12 long month to leverage more of the extremely capable and beautiful platform that they had right from the beginning? That's one year of delayed innovation, one year of untapped opportunities, one year of competitors to catch up, isn't it? You think a year is not that long? I claim it is! Recap what has happened meanwhile: Android phones entered the market, Palm Pre has been announced (and if speculations are right will also hit the US market before iPhone OS 3.0 is out), Nokia has launched its touch OS (S60 5.0), etc. etc.

Mobile OSGi is setting out to solve the *API innovation cycle problem*. In OSGi, new APIs can be loaded at any time, by anyone (who has the right permissions). Developers don't need to wait for X years for the manufacturer to complete the next static image version - they just pull the APIs they need and deploy them along with the apps. Internet firms can wrap their services into APIs and have them be used by 3rd party developers to create the next gen mobile apps for them. New business models (like the one Apple is to ship with 3.0: in-app sales) can emerge way quicker than before etc. etc. For sure, there's always more creative brain power outside the manufacturers engineering team, why not leverage that, why not to unfold the true creativity of the worlds developer community?

It’s sad enough that the phone hardware platform got to have a static lifecycle. But the APIs don’t need to be static, really!


xakcop said...

The core APIs should be static and I am sure that Apple understand that pretty well. Look what happens on the desktop side -- you have tons of APIs for Linux written by the "creative brains", dozen of window managers, dozen of libraries doing the same thing. For me this is the exact reason why all desktop applications for linux are piece of crap and why Linux is not suitable for desktop in general.
On the other side you have Windows and MacOS having well-thought (still not perfect) APIs provided by the OS vendor and if I want to create a GUI application or use my device's camera, I know what to do. Developers don't like diversity, believe me. If I want to create a window I want *one* API, not ten.
Of course there is some room for 3rd party services and this is right place for Mobile OSGi. Away from the core platform and APIs.

Mirko said...

Well, I think you have to distinct between core and everything else. I think it makes sense to close the system to an extend that only certain interfaces to the host system are exposed.

For everything else however, I think Jo is right. There are brilliant people working for apple and they are doing a great job, but there are others out there also doing pretty well. When you start developing your application you are most likely to hit a problem someone else already solved in a great or at least sufficient way. Why not allowing them to provide this as an API and let everyone in the need for such feature just refer to the exposed API? OSGi has a great way of dealing with that and although it is Java based, apple could certainly learn something from it. Maybe the "universal OSGi" working group might be an interesting effort for apple to look at ;-) Anyway, coming back to pure OSGi, I think it is important to leverage reuse in order to accelerate advance in technology. The way apple is closing the system is just hindering, although I understand why they are doing it. It's a trade off. The risk of introducing flaws is obviously higher in an open system than in a closed one..., a risk I am willing to take, but I might not be the reference here.

Just my 2 cents,

Jo Ritter said...

Indeed, we need to distinguish between real core APIs and higher level middleware APIs. What I am suggesting OSGi to be used for is opening the systems for middleware APIs. To stick with the iPhone example, among these thousand APIs there are plenty of typical middleware features Apple (or someone else) could have added way earlier:
- in-app Sales: This is an API apps can use to promote and charge for content sold directly out of the app. Pure middleware.
- iPod library access: this API provides access to your content, certainly not core.

A last comment to xakcop's remark about the failure of desktop Linux which ended up with tons of redundant APIs: OSGi comes with a properly designed versioning and package system which is capable to recognizing API redundancies, of supporting multiple versions of one set of APIs, has a strict defnition of required metadata, etc. For sure, once fully exposed to open public OSGi has to prove that it'll do better than the dll hell but I'm certain that at least the infrastructure provides better tools to do so.

yonny said...

The comment from xakcop seems to reflect the old (static) way of thinking about mobile. Modern operating systems do have a core set of APIs, but they allow for "middleware" on top of that to expose API's needed for specific cases. Oracle, IBM, Springsource etc ,etc all provide APIs as middleware that enhance the basic OS, and they have been very successful. This is what Jo is talking about with Mobile OSGi. It allows for innovation from the community on top of the basic OS platforms. My old boss Bill Joy often said that advancement comes from standing on the shoulders of giants. This is what the component model of OSGi allows. As the father of Mobile Java I fully endorse the Mobile OSGi platform as the best way to mainstream mobile devices as full computing nodes at the edge of the cloud.
Jon Bostrom

Wireless Camera Hunter said...

I always connect with friends through blogger. Nice post !!! Thanks for Sharing, I enjoyed reading interesting article.

jen said...

nice post