this space intentionally left blank

January 26, 2009

Filed under: tech»mobile

Mobile Site Machinations

Nokia's Mobile Web Server (a port of Apache paired with a dynamic DNS service) is one of those "because it's there" kind of things. Not only does that seem to be largely why they built it, simply to prove that it could be done, but that's the spirit in which I've installed it. Do I have any good reason to run a website from my phone?

In fact, this is probably the wrong question. The point of the MWS isn't just to drive a website, although that's pretty cool. It's also to open the phone up to the lingua franca of Web 2.0: HTTP requests. There's a whole world of information services out there standardized on exchanging GET and POST over the Internet, but it can't usually talk to a phone without going through a proxy of some kind. The Mobile Web Server changes that--take a look at the services exposed through a REST API to see what I mean. In this scenario, your mobile presence isn't a limited client to the cloud--it's a full-fledged node of its own, capable of being directly queried and extended with new capabilities.

In developing countries, it should be said, we're seeing applications that work the other way: computers are learning to communicate via SMS with phone users, or to transfer data over the SMS channel instead of using data packets. Mobile applications in the developed world have been forced to either adopt this method of communication (like the SMS functionality on Twitter, or Google's short code) or distribute special code as discrete programs for communicating--the mobile Facebook and Google Maps applications share a common method of talking to servers, but they install as completely separate binaries and can't talk to each other. This is, frankly, a pointless duplication of code, as well as going completely against the spirit of mashups that makes mobile access so intriguing.

That said, there are no doubt interesting pages that could be served from a phone, and good reasons to do so. It would certainly be a workable option for people with my paranoid fear of centralized coordination, if you could find a way to create lots of routes to the dynamic endpoint (or to let people know the IP address when the phone goes online). For notification purposes or short announcements, RSS is more than sufficient: it's versatile, lightweight, likely to be available on a lot of phones in nthe near future, and (as Daniel O'Brien notes in one of the essays I linked yesterday) reliable enough. People don't need 99.999% reliability, O'Brien correctly points out, and RSS readers will just keep polling until a site comes back up. Frankly, for dissidents, always-on hosting might even be a disadvantage.

Another trend lately has been using phones for data collection, taking advantage of the cameras, accelerometers, and GPS/location sensors built into the devices. Nokia's version of Apache gets access to all the APIs normally available to Python, including SQL databases and most of the hardware. The idea of making that data accessible via a web interface--or indeed, being able to interact with it and control it live--is pretty powerful. But more importantly, building that interface through the web server means that it's capable of being a self-contained presentation tool for the data it gathers. The phone may not be able to run the latest version of Flash or compile Javascript at full speed, but it could certainly host viewers in those languages for clients connecting over the network for a portable, no-install data-crunching session.

And finally, of course, there's the possibility of simply hosting a standard website on the phone. I can't imagine running Mile Zero this way, but there are some kinds of content that would be tempting just because of the accessibility of the platform--voice/audio posts, perhaps, or a constantly-updated picture blog. If nothing else, there's the "because it's there." Why host a web page from my phone? Well, why not?

Future - Present - Past