A mobile is with its user all of the time, including the legendary ‘by the bed’ and even ‘in the bed’ modalities. Alarm clock is still one of the number one non-communications apps for mobile! Messaging in bed - we’ve all done it (haven’t we?)

A mobile, as it’s always on and always with its user, provides an ideal umbilical cord for digital sustenance. It’s like a drip-feed. That’s why I call it a data-drip. It’s a unique feature of the mobile experience.

Unfortunately, we still don’t have a satisfactory architecture and accompanying design pattern to implement data-drip services. Yes, I can poke text messages to a user, but invariably this breaks the experience because the whole text messaging environment is out-of-band, not only in the IP connection sense, but in the application environment sense. Yes, it is possible to consume text messages into an application, including the push registry in MIDP 2.0/3.0. It is also possible to embed URLs in WAP push messages, although this technique remains underdeveloped and underused.

However, the data-drip pattern does not fit into any web-based architectures and patterns currently on offer. And this is where mobile is different. With mobile, concurrency and persistence is difficult, especially with web applications. This needs to be solved. There are various possible solutions, but I have yet to see anything emerge from the likes of Webkit to address persistent and concurrent web apps capable of supporting data-drip services, be they via SMS or via something like Push AJAX (e.g. Lightstreamer = way cool solution!).

One of the problems with data-drip services on mobile is that the whole texting ecosystem is cumbersome and fragmented. Unlike device fragmentation, this is simply unforgivable because it is much easier to implement, at least in theory. The major problem is still the charging issue and ensuring that users on different networks globally can sign-up. If I want to create a service that sends text messages to a user, then I’m required to pay for it, except in the case of reverse-billing for content, and then I need to set up various arrangements, quite possibly with various aggregators. It is not easy to implement a data-drip service in which the user subscribes (pays) to receive the drip (at a rate commensurate with their texting plan and bundles, not inflated premium-rate pricing).

Compared to sending data to an IP address anywhere on the Internet, pushing out a piece of data to a mobile phone is cumbersome. Again, it would have been relatively easy for operators to have solved this problem, but they have simply sat back, as per usual, and let money wash in from premium texting services (with extortionate margins) while missing an opportunity. There should have been a universal standard and method for enabling any Internet-based service to push data to any mobile in the world.

Forget that. Let’s have a universal standard and method for enabling web-based applications on mobiles to maintain persistent state and to asynchronously receive data drips over IP. Push AJAX is the solution, but this needs extending to allow application concurrency without all of the concurrent apps necessarily being active in the browser at the same time (which not even the brilliant iPhone can handle).

Technorati Tags: WAP push, data-drip, Webkit, Push AJAX, Lightstreamer