Ericsson as handset API broker?

According to this article, Ericsson is talking up a new developer initiative aimed at trying to establish a common API across a variety of different handset platforms.

At one level, this is a very sensible concept - I've been trying to convince network-side manufacturers that they take the phones for granted for years. Numerous network technologies - 3G, IMS, UMA and potentially femtocells - have been delayed or rendered useless because the infrastructure or standards folk thought that the phones "were the easy bit". And while implementing some of the "hard" nuts-and-bolts protocols is occasionally simple, that certainly can't be said for the "soft" user-facing applications and all-round experience. I wrote about delays in creating IMS-capable phones 2.5 years ago, and we're still waiting for things like RCS.

In an ideal world, the network would be "exposed" to handset-based apps, and the handset "exposed" to network-based apps. The network would know (for example) what the phone's battery level was like, or if it was on charge, set to "silent" or had limited available free memory - all valuable data for applications. And it could help guarantee security through certificates or other mechanisms. Conversely, a handset-resident app could query different networks' levels of congestion, speed, price and choose the best one (obviously a lot of server-side APIs are already standard, courtesy of the web).

My concern is that Ericsson may not be the best-positioned or most neutral broker - especially if its proposition is based on Java and IMS as this other article suggests. If there is to be a successful common API, it absolutely needs to work in BOTH operator-controlled and 3rd-party-controlled fashions.

As a baseline, it needs to be absolutely neutral towards the philosophies of "over the top" or "through the middle" application architecture. It's fine if its *implementation* can be skewed one way or another in different contexts, though. For a handset provided by and subsidised by an operator, you'd expect there to be optimised applications and control/billing suited to the carrier's preferred platform, whether it's IMS or something else. But for an handset provided through other channels - and especially if it is subsidised or provided by a non-operator player (maybe Apple, Google, Cisco etc), the converse should be true.

There's also an large open question about how this fits with initiatives like OMTP's BONDI, which is "addressing the problem that an application written for one phone must be rewritten again and again if it is to work on all phones" (sound familiar?), but which is using a web runtime and browser/widget world-view, rather than Java or IMS. That said, Ericsson's also a sponsor of OMTP, so presumably there's some alignment going on in the background somewhere.

I haven't heard full details yet, so I can't really give a comprehesive opinion. I'd love to be a fly on the wall in their meetings with Apple and Google, though...

EDIT:I just re-read the last paragraph of the EEtimes article, which talks about browser-based application environments, so I'm now a bit confused between the mentions of web, Java, and IMS involvement. I'll try to track this down.