Ajit Jaokar is the founder of the London based publishing and research company futuretext (
.mobi and Ajax : They don’t mix …
By Dr Paddy Byers
.mobi has been covered recently by C Enrique Ortiz and also Carlo at MobHappy.
Following on from their comments, this blog explores the idea of .mobi in a mobile Ajax world
First, it is assumed that there is a clear divide between mobile sites and non-mobile sites; there isn’t. I have a mobile web browser on my PDA that fully supports DOM-compatible scripting and XMLHttpRequest – but I only have a small screen and only key navigation. And I’d like to be able to navigate sites one-handed if possible. Full desktop sites don’t work well for the obvious reasons – they have large images, they don’t fit well on the screen, they rely on mouseovers, etc – but plain mobile XHTML sites that are AJAX-free also don’t get the best from the platform. Ironically they are less mobile-friendly because they require full page downloads for simple interaction rather than the kind of thing we can do with AJAX. So, ideally I’d like the site to figure out what browser features I have (some mobile-like, some desktop-like) and give me the best experience. I can’t do this now – perhaps the w3c device independence activity will give us what’s needed – but in any event it’s absolutely wrong for those characteristics to be embedded in the domain name.
Note: The UAProf doesn’t indicate what scripting capability the browser has, and whether or not the browser supports AJAX. The issue is that AJAX(and other new web technologies) are not formally standardised from a UAProf perspective and in practice site authors need to code to take account of the specific characteristics of each browser. If the phone has a browser that isn’t recognised, the UAProf doesn’t give sufficient information for the site author to know how to target it most effectively.
Second, the clear trend in AJAX app construction is to migrate to fully symbolic URIs that represent elements of the application’s state. As well as using symbolic URIs to represent some internal state (and then using REST to manipulate that state), these symbolic URIs become the top-level URL for the site at any given time. There’s a good example of how this works in Christian Gross’ book where he gives the example of an airline booking application. For a given booking there’s a URI that references that booking which is representation-independent (ie doesn’t encode any particular view of the booking), lifecycle-independent (ie is valid for that booking at all states of its lifecycle) and is session-independent (ie there is no state that the application relies on in a session cookie or any other browser state). What’s more, the reference is fully device-independent in that the same reference could be entered into a phone browser and it would then take you to the booking application in whatever markup system is relevant to that phone’s browser. In principle, it’s possible to manipulate the same booking from multiple browsers simultaneously, including from the mobile domain.
.mobi, by contrast, foresees islands where these domains do not mix; at least, they don’t mix a the level of the URI. That’s just not where AJAX and mobile web services are going. What’s more, the mobile web apps that are most likely to be successful and make money are precisely the ones that successfully achieve this data convergence.
So where does that leave .mobi?
It’s conceivably possible that a fully DOM-compatible PDA supporting XMLHttpRequest is in the minority in the mobile world, and more possible still that anyone outside of a minority in the US does not have an all-you-can-eat data tariff to soak up the XML goodness of AJAX, so this may not be an entirely representational start to the article. User agents are also never representational of anything really, except the diversity, disrespect for standardisation and general incompatibility of devices in the mobile space, and UAProf is even less useful for anything in my experience despite wonderful intentions.
And yet you’re absolutely right, the .mobi domain is a waste of space. Which idiot picked the domain – it takes forever to type on a nuemric keypad. The AJAX angle to the argument may be 5-10 years early, but the core point is right regardless…
Comment by raddedas — September 14, 2006 @ 12:00 am
I do not understand why you link Ajax and REST? Many non ajax application can be REST, while Ajax app does not necesseraly require to be REST based.
I agree that these are just two cool Buzwoord these days, but that’s all.
Anyway, I also agree that .mobi is confusing and not needed…
Comment by Thomas Landspurg — September 14, 2006 @ 7:56 am