Near time connection : An example of Mobile SAAS, Mobile Web, Mobile Widgets and Mobile Ajax in action ..


Near-Time is one of the leading on-demand, Enterprise 2.0 platform for cross organization collaboration. Near-Time combines blogs, forums and wikis and it enables business professionals to create rich interaction with their prospects, customers, partners and suppliers.

Near-Time has recently launched Near-Time connection which extends the Collaborative Capabilities of Near-Time to other Mobile Devices and to iGoogle via Widgets.

It is an example of a single interface / service (driven by the Web) and extending it to mobile devices and to iGoogle and thereby increasing the reach to existing (and potentially new) users.

By that I mean, while Symbian /Nokia support is absent at the moment on Near-Time; Nokia also supports Mobile Widgets in a big way. Hence Near-Time could easily extend the reach of their application to all Nokia/Symbian devices using the same Widget code base.

Through this strategy, application discovery will also be driven by the Web and via multiple channels (for instance – the Widget may be first discovered in iGoogle but the user may also have a Pocket PC device and may use the near-time application on the Web and also on the pocket PC.)

Finally .. By providing the ability to embed widgets into a home page, the user gets a customized product and at the same time overcomes the limitations of widgets themselves(i.e. the single, monolithic focus of a widget). The choice of launch platforms is also interesting (Web + iGoogle, iPhone, Pocket PC and the Blackberry)

I think leveraging the power of the Web, Mobile Web and Widgets by incorporating the ideas of Mobile SAAS, Mobile Web, Mobile Widgets and Mobile Ajax will be increasingly the way to go – fuelled by the greater uptake of the full Web on Mobile devices, Mobile Ajax and Mobile Widgets.

Mobile Ajax, Google Gears on mobile and Offline browsing

After two big announcements from Google, i.e. OpenSocial and Open Handset Alliance/Android .. I believe that the third missing announcement is Google gears on mobile. Google gears on mobile devices would solve a key problem for the Mobile Web and I have blogged about it’s potential almost as soon as the announcement was made.

With Android, Google has not gone RIA (Rich Internet Applications) but for a large measure, the rest of the world has already gone RIA for mobile browsers. If you accept that technologies like Mobile Ajax are now becoming mainstream just within two years after my now well publicised blog about the same topic Mobile web 2.0: AJAX for mobile devices – why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development – Part two , then it is indeed time to address offline browsing in tandem with Mobile Ajax.

In a nutshell, Google Gears comprises of a local database, local processes and a web server – with the logic being written in Javascript. Hence, Gears potentially fits in well with Mobile Ajax and Gears also fits in well with Mobile Web Widgets(and by that I mean Widgets created using Web standards as opposed to Widsets and similar products)

The acceptance of common standards between the Web and the Mobile Web is a good thing and while Gears is not a ‘standard’ – it is open sourced – and it’s acceptance on the Web would definitely help to promote it on the Mobile Web. As far as I can see, the only other group/body addressing this problem is HTML5 and even those efforts appear to be mainly to be for the Web(and not the Mobile Web)

While I am a big fan of standards, W3C etc .. in this case, I think Google is leading the way. And if they do the same as they have done in case of Android(An alliance rather than ‘doing it Google’s way’) – then we have the potential of a truly interesting service.

The most logical way to implement Gears on browsers is through a plug-in such as the Netscape plug-in API followed by Mozilla, Opera and most major players(except Microsoft). I am a bit unsure about Mobile browser plugin standards(as opposed to Web browser plugin standards) but I hope to find out soon. Google may well opensource Gears on mobile just as it does on the Web creating a de-facto standard if one does not exist.

Soon, I see Mobile development to be dominated by two open source products: Google Gears and the OHA. And that is a good thing because it allows other players in the industry(including Operators, device manufacturers etc) to have a role.

For instance, If vendors like Nokia, Opera and others support Gears in their respective Rich Web browsers – then we have a good way to overcome the fragmentation issue that has ailed the industry from the outset . Furthermore, it is an alliance founded on the basis of Open source with each party playing to their respective strengths.

The one additional bit missing here is security .. as a study of Google Gears on the web demonstrates. The implementation of Google gears on the Web gives some clues of the issues involved and we can expect the same issues on Mobile devices(plus security and device APIs unique to mobile devices)

As per the Google gears architecture on the web, some of the issues involved include ..

a) The lack of a data layer: For instance, AJAX calls can originate from anywhere within the code without an interim data layer. This is fine for existing Ajax applications since the only source is the server. However, when we also have local storage, there are potentially two sources (the server and the local storage). Hence, a common data layer is needed(which currently does not exist)

b) Features available offline: Not all features may be optimal offline – for instance rapidly changing stock quotes are best accessed from the server than offline

c) Modality – Managing the transition process i.e. switching between online and offline modes(explicit or user driven)

d) Synchronization: explicit, in the background etc

And then there is security .. a major topic in itself. According to the Google Gears site

, Gears follows the same origin policy

and security at the file system level is enforced by the Operating system.

However, when it comes to Mobile devices, there is a lot more in relation to offline storage and security. For instance

• Can the browser access content from removable media?

• Can the browser read/write data from the terminal’s file system programmatically?

• What restrictions are placed on personal data(stored in the cache) for ex data types like SIM contact data, Phonebook contact data, Diary elements etc which are normally protected but can now be cached.

There have been other references to Mobile offline browsing – most notably from the Register and CEO

To conclude, sqlLite is part of Android. It is also a part of Gears. Google could easily use a similar architecture and experience gained from Android to solve the problem of persistence in Mobile Ajax applications. A problem whose resolution would help the industry and encourage the growth on Mobile Ajax/Rich Internet Applications on mobile devices.

Comments welcome as usual

update from Stefan at intomobile

Thanks Stefan!


Actually Nokia is already implementing something called the Web Runtime with their next edition of S60 that will allow devices to do what you just said:

Motorola, in their next version of Linux, is also working on a web runtime.

What you want requires platform level support, something that even the mighty google will have a hard time with unless they pull a Yahoo 2 Go and build a mobile application platform in which developers work.

Who knows, too early to tell, but I agree with your basic logic that Google Widgets + Open Social + Google Gears for Mobile makes the most sense. The key is the implementation.


iPhone, Mobile ajax, Mobile widgets and insights for iPhone developers

On the eve of the iPhone launch, it’s almost obligatory to do a post about iPhone :)

With its emphasis on the Mobile web, Mobile ajax and widgets – the iPhone conforms very much to my vision of mobile applications when I said back on Jan 1 2006 that why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development (although then – I never thought that the iPhone would accelerate that vision so much)

Besides being good for the Mobile web, the iPhone will also set new standards for the whole industry.

How long can we continue to build old style WAP like applications?

How long will customers accept it?

Even those who have not bought the iPhone will have high expectations now.

The few companies like Opera and Nokia which adopted web standards and rich media

will be the real winners. Many like openwave have simply missed the wave .

In any case, with the genie out of the bottle there is no turning back

iPphone developers will be unique (at least initially) in the sense that they will mainly be from the USA and they may not have a background of working with mobile apps (often coming from the MAC development area)

So here are some of my insights for developers

a) Access to device APIs;

update: See clarification of this issue HERE

Another update:


I feel like a protector to walled gardens – however I stand by my belief that APIs must have some form of authentication.

This is not specifically a defence of Apple. But I believe that no one in the industry can afford to open up APIs without some restrictions/authentication.

For instance, as the phone becomes a wallet, free access to APIs would mean access to money. Similarly, other scams could be possible

Secondly, If Location is known, then there are protection and privacy issues especially for minors.

I believe for these reasons, we need some form of signing mechanism – i.e. a controlled access to APIs.


Many developers are disappointed because the iPhone does not allow access to device APIs. I believe that it is not absolutely essential to have access to device APIs. We can still build simple, useful applications which customers will like. Also, in many cases, device access may not be possible for more practical reasons like security, protection of minors etc. Thus, one would expect that over time some process like symbian signed applications will emerge and that would allow access to device APIs. The lack of such access is an interim measure in my view. It is not limiting in terms of the apps we can develop and we can still build useful applications even when we don’t have access to device APIs. Other comparable platforms like Nokia s60 and Opera are also in the same boat. Security and safety are important in this context and they cannot be ignored.

b) To me, the support for Mobile widgets is critical and one to watch. Have a look

at this excellent post from Niall Kennedy and also my post on the potential for the iTunes to be a delivery mechanism for mobile widgets. I am watching mobile widgets with great interest.

c) The rollout of iPhone itself needs to be watched. It’s interesting to see how the

iPhone will work with the second, third and subsequent operators. For an analysis of

this see – The iPhone is extraordinary not because of it’s UI but because it’s the tail wagging the dog ..

d) Since the iPhone is never going to be a mass market phone, the real winners here

will be companies like Nokia and Opera – both familiar with the Mobile web, Mobile widgets

and Mobile ajax.

Dan Appelquist also has similar views .. when he says ..

So, irrespective of whether the iPhone itself is a success (and if Apple’s previous product launches are any guide, it will likely have its ups and downs) it will be a wake-up call to complacent industry executives and a needed shot in the arm for efforts to expand the Web developer ecosystem into the mobile platform.

update July 4 : iPhone APIs 2.0 :)

Bling software: Over the air mobile ajax client ..


I met Roy Satterthwaite, CEO Bling Software when I spoke at the O Reilly Web 2.0 expo,

Increasingly, the space of ‘Javascript running on top of Java APIs’ is becoming quite crowded with Sun itself getting into the ring with Java FX. However, Bling is unique because it’s client can be distributed over the air!

I have yet to see another company making that claim and it could be disruptive because it solves the client distribution problem and widens the scope of the target audience. I would be interested to hear any views about this approach(or anyone else who claims similar)

From their web site


Bling Software is the first and only technology vendor to develop a fully extensible, cross platform, JavaScript interpreter for the mobile handset that is small enough to be distributed with content to consumers over-the-air.


Bling Software is the first and only technology vendor to develop a fully extensible, cross platform, JavaScript interpreter for the mobile handset that is small enough to be distributed with content to consumers over-the-air.

Standards based JavaScript authoring environment for fast and easy development

Asynchronous communications for faster loading and less delays

Easy data integration to existing websites and content via XML (E4X)

Rich media support for audio and video

Infinitely scalable, no server requirements

Over-the-Air downloading and updating of content-small footprint for easy fast and easy loading

Simple elegant declarative XML applications with embedded standard JavaScript

Cross-platform VM. Run across all different kind of handsets and operating systems from different manufacturers

Cross-carrier. Run on all the different operators


My talk at Ajaxworld: A brief summary of main ideas covered..


Yesterday, I spoke at Ajaxworld in New York on Deploying Web-Based Applications to Mobile Devices Using AJAX Techniques.

This is my third Ajax world(after New York and Santa Clara last year) and I am pleasantly surprised as to how many people turned up this year for my talk!

Ajax on Mobile devices is a subsidiary topic from the main conference (i.e. Rich Internet Applications on the Web) – and hence to see so many people attending what was in effect, the last session for the day, is great. In fact the room was full – and there were some people outside the Hudson Suite – where I spoke.

I can think of three reasons for this uptake:

a) RIA (Rich Internet Applications) is becoming mainstream – be they Ajax or Flex. For instance, for the first time, Oracle was an attendee and also a sponsor

b) Mobile Ajax is unexpectedly in the news thanks to iPhone and Mobile Widgets(The Mobile Widgets I predicted more than a year ago, iPhone was unexpected to all and will be significant for Mobile Ajax as I spoke yesterday – especially if Dashboard widgets make it to the iPhone)

c) And finally, there is widespread support from almost all browser vendors. Here in Europe, we focus on Nokia and Opera – but there were a number of questions about Windows Mobile – something I need to clearly brush up on a bit more!

Here is a slide summarising the top five things to take away from the talk

Some notes

a) By three musketeers, I mean the trio of technologies : Mobile Ajax, Mobile Widgets and WICD

b) The quickest benefits for Mobile Ajax are based on accessing the Web / enterprise data(because these applications don’t need access to device APIs). The best example of this type of service is Soonr

c) Mobile Ajax is more than a pretty face! See an article which I wrote a while ago elaborating this i.e. look beyond the UI to the broader architecture

d) Long tail applications and Widgets!! .. Mobile Ajax is the foundation of Mobile Widgets and Widgets span the Web and the Mobile Web(thereby enabling Long Tail applications)

Thanks to team at sys-con . Someone at sys-con said I am almost part of the family :) and they always help me out since I am one of the few regular European speakers. Thanks to Jeremy, Faut, Dion, Laurie and Megan for all your help.

Look out for our Mobile Ajax FAQ (I , Rocco and Bryan are writing)


Three musketeers image source:

Java ME as middleware to Mobile Ajax?


In previous posts, I have always been bullish about Mobile Ajax and also said that the iPhone acts as an unexpected catalyst to Mobile Ajax .

There is another, rather curious development which is also bringing Mobile Ajax to the forefront in an unexpected way.

In a nutshell, I would call it Mobile Ajax over Java middleware or using Java as a middleware to Mobile Ajax

The best known example of this approach so far is mojax from m-foundry

Using Java as middleware actually makes a lot of sense because at the moment, Java APIs have access to some of the lower level functions of the device. These include the APIs for the Camera, Bluetooth, Messaging, Address book, location etc. By using Ajax (essentially Javascript) on top of a Java middleware layer, we also overcome the other big limitation of Java i.e. porting issues which I pointed to before and also align closer to Web standards.

The basic approach seems to be to threefold: Use Javascript and Ajax functionality at the UI; Java as middleware and add some other elements like caching, offline capabilities etc to provide a hybrid application platform(i.e. using some web standards but not over a browser).

I welcome any development that moves the industry forward – in that sense it’s a welcome development.

However, many like C Enrique Oritz (CEO)

have said that Mojax is not true Ajax , and I have to agree with that. (Read CEO’s post in detail and you will see the technical reasons why). Rodney Aiglstorfer, CTO and co-Founder of mFoundry (creator of mojax) counters this argument saying that it is too technical

However, I think CEO is right here(but that’s not to belittle the work done by the Mojax team) because he points out areas where the implemenation is not truly Open Standards based.

It’s hard to ignore Open Standards on mobile devices because of the cost savings involved. This is happening all through the Mobile stack – for instance – take Mobile Linux where Motorola, NEC, NTT DoCoMo, Panasonic Mobile Communications, Samsung Electronics, and Vodafone have announced the non profit LiMo Foundation.

My point here being(and that’s what I think CEO is also saying): if you don’t standardise – you can’t really hope to go mass market.

Thus, companies like Opera benefit from working closely with the standards because the standards based solutions ultimately are open and cost effective especially when it comes to embedded/device applications, something enshrined in Opera’s vision and Google’s commitment to Open Standards

Similarly, companies like Soonr are building great Mobile Ajax apps which don’t necessarily need access to device APIs. Nokia has also committed to full web browsers.

Finally, from a technical perspective, nothing prevents browser vendors from gaining access to device level functionality. If Java and symbian can do it – so can browsers i.e. its just a matter of time.

Thus, I view this as an interim solution but certainly one that works.

In the final analysis, the question is:

a) Will developers like it? Will they see critical mass? Will they see revenue models?

b) Would end users like the experience?

c) Would the industry want to deploy it

So, the jury is still out on this approach but its good to see my original predictions about Mobile Ajax being disruptive coming to fruition

iPhone: A catalyst for Mobile Ajax


My optimistic views about Mobile Ajax are well known. However, last month Mobile Ajax has got an unexpected catalyst in the form of iPhone.

I have always favoured Mobile Ajax for reasons like:

a) I like the One Web (unified Web) theory.

b) I believe in Open standards.

c) Mobile Ajax fosters the adoption of Mobile Widgets and

d) Developers will adopt technologies which they are already familiar with

The story so far has been led by the Opera platform, with support from Nokia (who have introduced many devices with the full Web browser).

Soonr has been the best showcase application for Mobile Ajax.

However, an unexpected boost to Mobile Ajax has been provided by the iPhone.

I believe that the iPhone will always be a niche device and even Steve Jobs is very likely aiming for that (which is still a great/profitable business to be in).

However, like on the PC, Apple will end up raising the bar for many things – especially the UI.

On first impressions, the browser UI is great .. but even more so when you realise that the browser does not use either Flash Lite or Java.

So, it is good old fashioned full browser technology –aka – Mobile Ajax(and more).

This means legions of developers will try to create better UI emulating the iPhone

But the iPhone will never be a mass market phone! So, I believe that the industry will reap the benefits of the skills base from these developers.

Others like Eli Dickinson of Fierce wireless have also spotted this trend

I predict this year, Mobile Ajax will become much more common – although we not call it ‘Mobile Ajax’ – actually any full browser app could be potentially Mobile Ajax application and the iPhone UI will lead to developers adopting Mobile Ajax(and thereby benefiting the industry as a whole especially more mass market solutions like the Opera platform)

Image source:–has-tabs-227412.php

Mobile Ajax – more than a pretty face



Note One : I would be interested in hearing and blogging about your company if you are developing Mobile Ajax applications and to brainstorm/elaborate the ideas in this blog. Please email me at ajit.jaokar at if you are doing something interesting

Note Two : In response to Patrick’s comment on my blog below (Update): Why focus on a specific technology like Ajax? Actually, I am not focussing on a specific technology like Ajax. I am however focussing on Open Standard Web based technologies that foster rich internet applications. To me, the Web is more than the Browser. For example, at least Widgets and RSS (in whatever incarnation it gets standardised by the W3C) are important. Thus, Ajax for me, is a way to provide RIA (Rich Internet Apps) using Open Standards but it is not the only way.

Note Three : An example of taking a programming only view can be seen at Tom Hume’s blog (I have a lot of respect for Tom’s views in general – but I am using this to illustrate my point) Tom quotes (not his own blog) : AJAX on the web is a hack, every developer knows it’s a hack. That ignores the bigger picture and looks at it from a purely coding perspective. In contrast, the blog he is quoting from by Mike Rowehl is more comprehensive but it also does not make any reference to the architecture. In general, the impression one (wrongly) gets is ‘Mobile Ajax’ is like ‘Using Ajax on a mobile browser’ and I am saying that: That’s not the case. You need a different architecture and we need to take a more strategic view. By the way, it is independent of where the application could be deployed(at Carriers or at service providers or even Corporate as I discuss below)


Today, I spoke at the Mobile User Experience conference organised by Osney Media

This was a gathering of folk interested in Mobile UI, more used to traditional Telco WAP/SMS applications than some of the Ajax driven Rich Internet Applications becoming increasingly common on the Web

This blog is in response to a question from the audience.

I promised that I would blog about this topic because I had a meeting to attend to afterwards and had to leave immediately after my session (sorry Ben/Vicki – feel guilty coming for lunch, attending my session and then off immediately – but I hear it was a good conference! Will see more of it next time round ..)

Anyway, .. In my talk I mentioned that Mobile Ajax was more than a pretty face.

I subsequently said that many (especially people from a programming background) – take the definition of ‘Web Ajax’ literally and apply it to Mobile Ajax ‘as it is’. This means looking at the Ajax acronyms (XHTML, Javascript, XMLHttpRequest etc ) and then extrapolating them to Mobile devices

This is very limited thinking .. because it excludes something else that is missing in a mainstream Mobile Ajax application.

That ‘something’ is ‘Cloud computing’

Cloud computing is a term recently popularised by Google CEO Eric Schmidt . This rather long Wired article gives a fascinating insight into this new computing paradigm of Cloud computing summarised by

The desktop is dead. Welcome to the Internet cloud, where massive facilities across the globe will store all the data you’ll ever use. George Gilder on the dawning of the petabyte age.

By more than a ‘pretty face’: i.e. much more than the UI.

Since Soonr is the best example of the use of Mobile Ajax, I shall discuss these ideas in context of Soonr

(As I said, if you are working on something interesting in this space, please email me). I have blogged about Soonr before - so I am not going to go into details of the application itself.

Conceptually, the Soonr application does something quite simple i.e. it allows access to files on your desktop.

By virtue of using Mobile Ajax, it already benefits from a good UI, open standards (non proprietary technology) and the benefits of browser based application deployment

However, if we look at only the ‘Mobile Ajax’ component, we are missing out far more because what makes the Soonr application interesting is: it combines the UI and data management capabilities of Ajax with Cloud computing with other technologies like transcoding

Some of these technologies (like transcoding) have been around for a long time (as I recollect, even as early as 2000/2001) for example this company but these applications never worked in practise. Today, we have the entire Cloud architecture and transcoding, image panning etc are merely components in the bigger picture

For example, a word document on the desktop could be converted to a jpeg and stored in the ‘cloud’. It could then be deployed optimally on the mobile device including features like zooming/panning etc.


The results are very powerful.

And that’s what I mean by ‘more than a pretty face’ i.e. if you look at it only from a programming perspective or from a UI perspective ignoring the architecture – then you are missing the whole point!

A secondary consequence of the above discussion is: Mobile Ajax could be well suited for corporate applications (security/permissions etc could also be managed at the middle tier)

Corporate mobile applications is where the action is at the moment and this scaleable(and relatively cost effective) architecture will benefit from the moves Google and others are making in this space (Will Google cloud displace Microsoft) .

For instance: Motorola acquired Good technology in this month . Nokia acquired Intellisync also in this month.

These moves are all going for the hallowed Blackberry market.

In that context, the corporate incarnation of Mobile Ajax becomes very interesting because the pieces are there and they are cheaper and cost effective to deploy (because browser based/Open standards etc etc)

The paradigms used here are also actually not new. If you follow the architecture of BEA Tuxedo and more earlier IBM CICS (no I am not that old! I had to ask someone about CICS – but I have worked with Tuxedo at PeopleSoft (now Oracle)) – the ideas are very similar BUT with a ‘Web’ hat on

Some of these ideas above need more elaborating(for instance the corporate role of Mobile Ajax in light of recent moves by Motorola and Nokia) but you can see what I mean by ‘Mobile Ajax is not just a pretty face’ .. If you miss out the architecture, you are missing the whole point!

Image source: cecm . The site is in Brazilian/Spanish – so not quite 100% sure what it is about – but I know a pretty face when I see one :)

What mobile AJAX can learn from the fragmentation of Java Me

By Paddy Byers


Edited by Ajit Jaokar


As we have seen from previous posts in this blog about Mobile Ajax, Mobile AJAX has a lot of potential. However, many questions still remain about the details of how Mobile AJAX could be implemented and exploited.

Specifically, this post discusses the problems that occurred in the evolution of Java ME (formerly called J2ME) and how Mobile Ajax and other browser technologies can learn from them; both in terms of the browser platform itself, and the associated developer ecosystem.

I’d welcome discussion on how to resolve the issues that are raised.

Mobile apps aren’t just about interactivity

Many inherent advantages of browser-based solutions have been articulated clearly in the preceding posts, and AJAX gives a dramatically superior level of interactivity than was possible with conventional XHTML; but the truth is that AJAX has only just improved interactivity to the point that it is good enough to be a credible experience (assuming services are targeting a typically specified feature phone and aiming for modest level of richness in visual experience). From the point of view of the interactivity enabled, AJAX could be likened to an early MIDP 1.0 Canvas-based application on a typical interpreted virtual machine.

The analogy with MIDP 1.0 doesn’t stop there.

The current mobile AJAX environment has many similarities with those early Java ME days: there are maturity issues (e.g. only one or two implementations, no common behavioural specification or precise API specification); ecosystem issues (eg a developer community naively believing that desktop implementation approaches will transfer seamlessly to mobile); and market issues (a broken value chain as it relates to the proliferation of technology enablers). The painful failure of early attempts to use Java ME as a service delivery platform should be a clear warning to the new generation of web 2.0 service providers aspiring to extend to mobile.

The key parallels, however, are in the level of platform integration offered.

Much of the mobile AJAX discussion has focussed on interactivity and connectivity aspects; but the problem is that the services that extend effectively to mobile will be those that successfully harness the mobile platform and its capabilities.

Some of these include SMS/MMS, multimedia capture, interactive multimedia playback, location, Bluetooth, etc. To implement these features, we require access to the platform i.e. device APIs.

Real mobile apps are not simply a thin projection of an interactive interface to a web-based application.

One of the main reasons for the failure of MIDP1.0 was that none of the key platform capabilities was exposed to the java programmer.

Many – nearly all – potential mobile applications, even if 99% implementable in Java ME, turned out not to be viable because of a critical dependency on some platform feature that simply wasn’t accessible in the Java ME environment.

The Java ME community realised this early on and sought to address it by extending the scope of the platform.

Unfortunately, this is where the problems really began.

Unilaterally defined APIs (in the case of MIDP1.0, this was primarily audio and security) were made by manufacturers and also by operators; and the community process later created formally standardised APIs.

Several years on we have platform APIs that have functionality gaps and are inconsistently implemented; further, there is no common policy for the deployment of APIs, either between operators, within a single operator, or even among the devices of individual manufacturers.

The resulting fragmented environment and ecosystem problems are well documented.

The key point is that Sun, to its credit, set out very deliberately to ensure that the java platform did not get fragmented and tried to put in place every technical, legal and commercial measure to implement its strategy – and it still failed.

Implementation interoperability must be addressed proactively

The current desktop browser market contains a small number of players with comparatively well-understood differences. Content authors can ensure that content is interoperable by coding directly to cater for those differences. Basic market dynamics force browser providers to fix problems and keep functionality in step with the market leaders.

The mobile browser market is different.

For one thing, it is still not following the full web browser standards. Also, there are multiple providers and already some fragmentation in respect of functionality; scripting interoperability is especially limited as a result of weak (or nonexistent) DOM implementations underlying many mobile browsers.

There are also few market pressures to correct this – operators are not (yet) mandating full browser functionality (such as AJAX); much of the functionality is not formally specified by W3C or another body; there are no independent conformance or interoperability tests.

Simply leaving this implementation interoperability issue to market forces to address will hinder mobile AJAX substantially. The operators have a position in which they could either improve or inhibit interoperability.

Possibly the worst of all outcomes is in fact the most likely, which is that a requirement to support XMLHttpRequest and certain scripting functionality is made mandatory, without the detailed technical specification and conformance backup needed for manufacturers to do it reliably; the result will be all manufacturers scrambling to incorporate weak but technically compliant implementations, stalling all efforts for genuinely functional and interoperable implementations.

This interoperability challenge should not be underestimated.

Contrast the browser environment with Java ME in which API specifications are developed under an open and formal process, there are tens of thousands of conformance tests, conformance is mandatory under the license terms for the technology, etc – and still interoperability is poor.

The definition of platform and extension APIs must be decentralised

The Java ME strategy is to define all APIs through an open, formal and consensual process which is centralised. When a requirement for a particular API is identified – location-based services, say – the various stakeholders (operator, device manufacturer, content developer, technology provider, etc) form an expert group to develop the API and associated resources and make it available to the industry. The aim, of course, is to avoid the fragmentary effects of there being multiple independent and competing APIs.

However, the centralised nature of this approach is one of its biggest problems.

First, consensus takes a long time and APIs arrive too late to be useful.

APIs become over-engineered because they not only have to meet the immediate need but also any other foreseeable future needs and edge cases – because once defined they can rarely be extended.

The process, in certain cases, also becomes mired in the competing technical and commercial agendas of expert group members; and the business model surrounding the resulting reference implementations and conformance test suites are problematic, which delays uptake, or stops it altogether.

Ironically, these issues then themselves become the cause of much fragmentation.

Due to cost and the risk of delay, manufacturers and operators do not incorporate new APIs unless there is a clear commercial need; and when they do, they all make different choices as to which capabilities to include.

Prior to standard APIs being available, operators and manufacturers still create private APIs, which must then be supported on an ongoing basis and contain a slightly different feature set from the standard so content cannot easily migrate to use a new API.

What’s needed is a decentralised process which allows platform owners and service providers to define and implement their own APIs.

Although at first sight this would appear to create fragmentation, it doesn’t provided that there’s also a way of writing and deploying libraries or wrappers that can implement one API on top of another.

It’s analogous to using WSDL to specify web services – there doesn’t need to be a centralised definition of any given API because the relationship between alternative APIs is explicit and users of those APIs can react by writing wrappers that implement one in terms of the other, or write their own higher level abstractions that can sit on top of either.

The proliferation of widgets in desktop web apps shows the power of this decentralised approach. The potential role of widgets in mobile web apps is something Ajit discusses extensively in his book.

How to make it happen?

None of these issues requires new technology – the industry has the capability to do all of it. But it will only happen if the market incentivises the relevant parties – the browser providers and device manufacturers – to make it happen. The operator, in principle, is sufficiently resourced and has sufficient control to do this – but so far the operator community doesn’t seem to have realised the significance of the opportunity, let alone confronted the issues that have to be resolved.

Mobile Ajax: The architecture of Mobile Ajax applications ..


I met Jesse James Garrett when we both spoke at Ajax world expo (thanks to Jeremy Geelan – Group publisher of sys-con media for the intro!).

No prizes for guessing that we were discussing Ajax – more specifically Mobile Ajax.

I have talked about Mobile Ajax before on my blog and as many of you know, I believe in the power of Mobile Ajax to transform mobile data applications and to overcome some of the limitations we see today in the industry. Specifically so, in context of full browser applications i.e. browsers following the Web standards as closely as possible.

I mentioned to Jesse that I would be happy to explore Mobile Ajax in my blog and Jesse was kind enough to agree to comment on what we find.

So, watch out for a series of Mobile Ajax blogs

Most people take a very simplistic view of Mobile Ajax – generally leaning towards ‘Google maps on Mobile devices’.

That can be best described as ‘limited thinking’

Architecturally, what I am discussing is a bit more complex. This recent wired article about Information factories/ Internet cloud architecture or the dawn of the petabyte era provides a hint.

It’s a bit verbose but the synpopsis is

The desktop is dead. Welcome to the Internet cloud, where massive facilities across the globe will store all the data you’ll ever use.

I believe that the combination of cloud arcthiecture(driven by cheap storage) coupled with the capacity of Mobile Ajax has a lot of potential to create rich applications (by both carriers and Service providers).

The only company I know at the moment who is doing something similar in this space is Soonr. I would be interested to hear from you if you are doing some interesting work on Mobile Ajax

Watch this space!