Mobile computing vs. Mobile living
Charlie has a great post titled Mobile Computing vs. Mobile living, although I might have called it “Mobile devices vs Mobile platform”. It calls out the distinction again of background vs foreground devices. There are definitely infrastructure differences required for each class of use. For instance what would it take for a device like a PDA to act more like a mobile living device than a mobile computing device. The first thing that comes to mind for me is asynchronous notification. Otherwise of course it’s a foreground only device, and the notification mechanisms we currently think about are all tied to carrier networks. So how do we come up with a messaging system outside of SMS that allows for background operation by a device?
We’ve seen some efforts at defining standards for messaging and presence, but I think it’s safe to say they haven’t gotten nearly as far as some of us had hoped for. I laughed, I cried, I yelled, I tried to deny the failure. But I’ve come to accept it. The best thing to do is figure out why and try to move on. Lets assume that somehow we’re able to come up with a mobile device that can connect to the data network every once in a while (802.11 or cellular, whatever, but lets stick to IP based network functionality) and interact with some kind of messaging system. One of the major gating factors there is that data exchange at the IP level is relatively expensive operation. It takes a long time to do, draws a lot of power, etc. If you have a smartphone try setting up the email client on it (not push email) to poll your mailbox every 30 minutes. Even if you get no mail, the extra power draw required to pop onto the network and check a simple status is enough to seriously impact battery consumption. If you’re actually using your phone to talk on it you’ll probably end up with a dead phone before the end of the day. That’s the first roadblock obviously.
The second is the spam problem. If anything anywhere on the internet were able to deliver messages to this messaging system tied to devices in pockets all over the world - of course there would be people out there sending spam. The proper way to deal with this one is always really hard to identify. Personally I side with making the infrastructure as transparent and simple as possible and leaving intelligence in the endpoints. I favor filtering done on mailboxes over the blocking lists applied at the server level. This means that whatever this messaging system is it would have to have some kind of filtering built into the client/handset software. I think that might be the only real way to deal with it. There are more elaborate systems, but I’m pretty sure the complex solutions would never work out. Stuff like giving a signing key to anyone allowed to message to you and checking sigs on inbound messages. There are problems like using that messaging service from another system where an identical set of keys doesn’t exist. In the default form the filtering software could just be a whitelist applied on the handset. Ugly, but maybe enough for the average user.
There are other issues to work in there, but with those two solved we could at least get started figuring out how to move from mobile devices to mobile living.
October 20th, 2005 at 1:16 am
FWiW (not a whole lot) using gmail as the mail server manages the spam-filtration quite well for my treo, and a 30-minute polling delay, just as you described, keeps me on the phone and email-aware all day without battery trouble (I do suppress mail polling from 11PM until 7AM). Now if I could just get yahoo and flickr not to choke the Xiino browser… :)