Tuesday, April 06, 2004

I gave a short presentation at David Isenberg's WTF workshop (conference?). I've started to write about how to retake control of the Internet at the edge but am, perhaps, trying too hard to explain the concepts. The constraint of an 8 minute time slot forces me to focus on the key concepts. Even then, given the chance, I feel obliged to go into more detail when I commit myself to "paper" even when it's virtual paper.

I thank Heath Row for taking the time to summarize my 8 minute presentation in a few paragraphs. It's an extreme reduction but does cover the essential points. I do, however, need to clarify the last paragraph which is a tad garbled. Hauling bits is not bad; it's just not as glamorous as hauling garbage. It's the marketplace process that is inexorable.

I can't fault Heath for not getting it quite right -- I'm amazed how much of the workshop he captured. It was a short summary of a talk that was already abbreviated. I had to omit any discussion of the importance of using cryptographic capabilities to give those at the edges control. I also didn't go into how the same principle works for wireless connectivity where spectrum allocation is the stifling middle.

The short presentation is useful in a venue which allows me to talk to people and answer their particular questions. I can also go into more detail afterwards in talking to those whose curiosity I piqued.

For me the real value in giving such a presentation is that it gives me immediacy of a live audience. It's only by speaking to people that I learn how to explain the ideas. It's only after a lot of practice that I can hope to explain the ideas in an essay.

As a by-product of following Heath's links I wended my way to "Putting 40,000 Readers, One by One, on a Cover". Reason magazine is printing each copy with its own cover containing a satellite image of their neighborhood. It's a clever extension of the practice of printing the subscribers address on the cover. It shows some understanding of communicating edge to edge in a medium that is traditionally focused on the broadcast model. It's a sign of things to come as the end-to-end concept of the Internet becomes part of our culture.

I have a GPS system installed in my car. I would rather have a choice of navigation software and mix and match capabilities. I could then do something as simple as pointing to an address in my contact list and find the route to the destination. Or use the same information to phone some one and then have them send me the address in a message. Even if I can't do it all now I should be able to write software to add the capabilities.

The idea is very simple -- just run a navigation program on my PDA or computer instead of having to have a system built into my car. In fact I've tried this and was hoping to write about it as part of the larger topic of adding my own capabilities to the car. I'm still planning to write more about the topic but, unfortunately, it's more about theory than fact.

Instead I've had to write about why it is important to provide opportunity rather than solutions so I (and others) can define the behavior at the edge. I've written about the problems of Bluetooth in the past but it's hard to argue against a partial solution because it's easy to find examples that "prove" that it works. In fact, I am making another attempt to explain the problems with Bluetooth because I've run across a site that seems to be dedicated to its virtues. Science (and engineering) advances by disproof -- stressing concepts and understanding where they fail in order to avoid generalizing too much from accidental or isolated success.

In the case of Bluetooth, it fails because it knows too much and frustrates innovation. When I've tried to use a Bluetooth GPS unit in my car I've been frustrated because the connection between the software and the device is very dependent upon the path. Bluetooth doesn't have a native concept of a GPS unit. Instead I have to assign it to simulation of a legacy serial port (as if it were a dialup modem) and the connection is very dependent upon maintaining the path. It's not just that failures in the path make the connection fail, the failure is very hard to diagnose!

An 802.11-based solution has the potential for being very much better. I could have the application hail for any nearby GPS service providers or enter the identifier for the server. Since I'm not limited to pairwise relationships it's very simple for the GPS unit to service multiple clients. The connection is a general packet connection that is not dependent upon the particular path -- all that matters is that the software application and the GPS unit have a relationship. It doesn't really matter whether it's 802.11 (WiFi) or a wired connection or some combination. The packets can be routed between segments.

In practice the IP story isn't perfect since the relationships are dependent upon IP addresses but the solution that I am working on is to move the definition of the relationships to the edge -- the software application and the device would have their own identifiers rather than being dependent upon the IP address.

I don't have that option in Bluetooth -- instead I must wait till some committee decides on how to add the capability and then wait for it to get deployed. There isn't the opportunity for iterative development.

The tragedy of Bluetooth is that it has displaced the simple Internet-based solution for GPS units. At least so far. The reason is simple -- a closed solution looks better in a PowerPoint (i.e., product marketing) presentation than an open solution. The result is that we don't create a marketplace but simply sell products that work in some cases. Those of us who protest find ourselves trying to explain what can be to those who can only understand what was.