There are a set of requirements that are unique to mobiles that ‘desktop-to-mobile’ browser evolutions tend to overlook, as do most designed-for-mobile ones. In essence, these are capabilities that would allow the following:

1. ‘Persistent web applications’ - Web apps/content that update in the ‘background’ (i.e. a web-based standard for ‘on-device portals’) and that also enable instant access to previous or new web sessions via cached pages
2. True asynchronous AJAX-push (in-band)
3. Extending the events model to handle SIP and/or XMPP sessions to allow web front-ends to real-time apps within the IMS (and more generally SIP/XMPP) ecosystem, or alternatives.
4. Scheduling methods to control offline/online browser updates

What we’re talking about here essentially is integrating software messaging paradigms with web presentation methods. This requires a different architecture to standard browser configurations, introducing a background process to handle messages, route them and notify the user, allowing updated web pages to pop to the foreground etc.

I first researched this approach to mobile browsing whilst investigating paradigms for IMS applications, which still remains a stalled part of the mobile 2.0 evolution story. However, I don’t want to get too distracted by IMS per se, but the possibility of mashing real-time services with web-based ones, or adding web presentations to real-time services, requires a useful architecture to combine the two domains, whilst taking care of the very important consideration of battery life.

The issue with extending any messaging architecture to mobile is the amount of network chatter, which can very easily drain battery life. This isn’t an easy problem to solve without middleware to provide a message throttling and aggregation function. However, sooner or later these types of problem will need generic architectural solutions, especially as we move towards increasingly chatty event-driven services with fine-grain location/context updates and presence updates etc.