The personal device connectivity dam

Verizon is talking about opening up their network to phones not sold through Verizon. Is this the start of something big?

Well, that question leads to this long ramble on the sorry state of personal device connectivity.

First, let’s do the overview:

Personal devices follow PCs by 10 to 12 years. That is, when you whip your phone out of your pocket, you are grabbing a 12 year old PC – adjusting for form factor changes and such.

We can expect what happened a decade ago in the PC world to happen in the personal device world today.

So, what happened 10 to 12 years ago in the PC world?

Easy question. Win95 came out! A working, widely used, multi-tasking OS for PCs. Oh. And the Internet. But, hey, finally, after all these years, on an obscure blog, Win95 gets credit for being the enabler of the “Internet” as it’s thought of today.

Back to personal devices and Verizon.

There are plenty of calls for a CarterPhone decision for the cellular industry. Is the Verizon announcement a step toward the same end goal?

Yep. But, it’s a phone company step. The devil’s in the details. Apparently, the device/phone maker must get the device qualified by Verizon. That could be a step similar to that which land line phone devices must take. (They need FCC clearance.) Of course, that you, the phone maker, need to get the approval stamp from Verizon implies you need the same stamp from N other phone companies. Not gonna happen, folks.

Oh well. Anyway, the Verizon announcement can be cheered as a crack in the wall.

We’ll see the herd of carriers respond. Expect a variant of the Verizon announcement from the GSM guys. If the carriers get in a downhill snowball rolling contest, then things could get exciting. For starters, the GSM guys could, for instance, band together with a single point of device validation and skip individual carrier validation.

BTW, let’s look at CarterPhone a bit.

Before CarterPhone, two things were true:

  1. You could not hook a non-Bell phone to the network.
  2. You paid for each extension phone you got from Bell.

Usually, when people think of CarterPhone, they think of thing 1.

Consider, though, thing 2 in a cell phone world.

What if you could run 6 cell “phones” on the same account at the same time? Sure, thing 1 would be true, too. That is, you could get these phones from anywhere. But the interesting thing is thing 2.

Now think about the Amazon Kindle.

Never mind its misfortune of having no market (as the gadget geeks’ $400 bills are all going to iPhones at this time).

Never mind its misfortune of not being available for evaluation. (Do you see them at Frys and CompUSA?)

What’s interesting about the Kindle in the context of the Verizon announcement is this: what we’ll be seeing when the dam finally breaks on device connectivity are a lot of “extension phones” – that are not “phones” at all!

Forget thing 1: being able to buy a phone from someone other than your carrier. If you use a GSM carrier (e.g. in the US, not Sprint or Verizon), you’ve had that ability for a long time (except, of course, that you must still buy a phone from the carrier on easy, monthly installment payments – whether you get an actual phone for your payments or not).

What you’re seeing with the Kindle is yet another odd-ball device that can really leverage ubiquitous connectivity. Once the dam breaks, you’ll soon be carrying several of these devices. And your exoskeleton (a.k.a. your “car”, “automobile”, “wheels”) is sure to sport a gob of such devices. Remember that the limiting factor on personal devices is power. Your exoskeleton has unlimited power available all the time, relatively speaking.

Which gets to: why do exoskeletons not provide a device platform? Odd, that. The manufacturers even pay Apple to connect to iPods! The car guys of the year 1910 must be spinning in their graves.

Internet oddity

Have you ever noticed that Google has skipped a UI beat in Google Maps and Google Earth?

Try entering a latitude / longitude value to either.

Unless you get it exactly right, both systems fuss and stonewall.

Why?

Is there some silly patent out there?

Anyway, it turns out that parsing lat/lon gets dirty fast. Sort of like parsing arbitrary time/dates.

Here’s a shot: /cgi-bin/latlon_cgi.py.

Har, har. Should someone write a GreaseMonkey script to “fix” input to Google Maps with an XMLHttpRequest? That would be keeping in the Web 2.0 river.