At a recent developer conference, I listened as the keynoter, Bruce Scott of PointBase (Scott cofounded Oracle in 1977, where he was coauthor and coarchitect of Oracle 1, 2, and 3), spoke about the problem of wireless bandwidth. He shared his thoughts on the subject, saying that the best wireless applications were those that did as much on the client as possible, and then synched, or sent the necessary data to the server. It sparked a great deal of thought on my part and, I think, for many in the audience who were looking into deploying applications wirelessly. This month's editorial is inspired by that keynote, and the extension of the points that Scott raised.

It was an interesting theory, because it's the simplest solution to the wireless bandwidth problem that we've been covering; it's something that the industry is constantly talking about needing a solution for, and it's the simplest idea put forward. It's a wonder, but not a surprise, that it's not suggested more often.

Many of today's wireless applications are designed as much for tomorrow as they are for today. That's a nice way of saying that many of them, as I'm sure you know, are quite slow. When you talk to the application providers about performance improvements, increasing available bandwidth seems to be the fastest option to come to their lips. News of 3G for the long distance apps, and of 802.11a and other new protocols for faster limited range transmission, are the easiest way for application developers to solve the problem of bloated apps. Because it's more difficult, very few people are asking the question, "If the speed isn't there yet, why develop as if it is?"

That's a very good question that developers should be asking themselves when they are creating applications for today's wireless world. If as much of the application as possible resides on the client side and is cached for faster performance, then the hits to the server and the use of airspace and bandwidth can go down dramatically.

Is a member of the sales force, who gains huge leaps in productivity by going mobile, as productive as he can be when he's holding his PalmPilot out the car window to synchronize with the office, as the battery quickly drains? Or does it make more sense to offload that data in down times, or at the end of the day in a cradle back at the office?

Buffering is another important side-solution to the bandwidth and speed problem. On my BlackBerry, for example, as e-mail threads get longer, I'm constantly scrolling to the "More" option to display more text. I would love if it was smarter, and as I scrolled down, it sensed "Hey, Rob's reading a lot again," and before I even clicked, it was already receiving more message data for me. Likewise, it could display the subject almost instantly and, while I was clicking on it, continue to download. There are of course some hardware limitations to this, but nothing that can't be worked around with smart programming.

Another huge ramification of all of this goes back to a point I raised earlier - battery life. It's simply not increasing as fast as the technology is. No need to look further than your cellphone, for example, to see that its battery life is great, lasting for days at a time...when you're not using it! But a few hours of talk time, and the little low battery indicator is quietly chirping its sounds of death in your pocket.

Other wireless devices run into the same problems, and as screens enlarge in size and enter the world of color, battery performance is becoming more and more of an issue, as much as bandwidth limitations are.

Every effort needs to be spent on making the most efficient devices to run on today's technology, alongside the efforts to push technology into tomorrow.