Bob Cringely has an idea:

I'm preparing a number of experiments using a Linksys WRT54GS 802.11g router mounted on the roof of my house in Charleston, SC. The router is running Sveasoft firmware that gives me direct control of transmitter power if needed. I'll be testing it with a variety of antennas, mainly omnidirectional but perhaps I'll try a sector antenna, too. The other end of the wireless connection will be a second WRT54GS mounted in my funky homebuilt airplane. Operating the pair of routers as an Ethernet-to-Ethernet bridge will give me much higher performance than I could ever expect from just using a WiFi card in my notebook computer. And I'll be testing a variety of antennas on the belly of my funky airplane, too.

What I expect will happen is I'll be able to fly near Charleston and connect to my home network at 1-2 megabits-per-second. I'll learn which antennas work best together. I may even place or receive a few VoIP phone calls using phone software running on my notebook computer. It will be interesting to see how far I can get from Charleston before losing service. It will be VERY interesting to see whether I can connect to WiFi base stations other than my own. I'm guessing such war flying will be possible, though I can't guess how reliable.

Now -- strictly because I am twisted this way -- let's take this experiment a step further. Sveasoft supports mesh networking, though with a practical limit of three hops. Aerial WiFi links of 10+ KM ought to be possible and maybe a LOT longer. The hardware cost of a WRT54GS and antenna are on the order of $100. There are, at the moment I am writing this, more than 1,000 small aircraft flying on IFR flight plans in the U.S. So for not very much money you could have a 1,000-node aerial mesh that could serve not only airborne but also terrestrial users. Triple the money, and you could put in each plane a Locustworld mesh with two radios for each node and truly robust mesh networking.

There are 25,000 mobile phone cells in the U.S., but AirCell pretty much duplicates that network using 115 specialized cell sites aimed skyward. While WiFi ranges are less than cell ranges, a 1,000-node mesh is huge -- effectively bigger than any hotspot network now in use. There have long been proposals to park Internet hubs in the sky over major cities in balloons or circling aircraft, but the problem is always the cost of running that satellite in the sky. This solution eliminates that cost of operation, replacing it with a symbiotic relationship where aircraft owners benefit from volunteering the use of their planes by getting free airborne Internet service.

Fast Company writes: "Three techniques are emerging that could push online ad revenues even higher: contextual ads, behavioral ads, and local ads."

InfoWorld (Jon Udell) writes that "according to Collaxa's Edwin Khodabakchian, a pure visual development tool for process orchestration is still a long way off...BPEL (business process execution language) is the XML-based language of Web services 'orchestration' — that is, a means to connect multiple Web services to create end-to-end business processes."

EK: The idea is: Accept BPEL as a first-class language, understand the tasks of the developers, and create the equivalent of the JDT [Java Development Tools] for BPEL within Eclipse. And we have the visual [tool] as well, for when the visual is important. But we never lose focus that it’s a development tool. We’re not trying to build a high-level Visio-type thing.

IW: That is, of course, what a lot of people are expecting to see.

EK: The way I describe the evolution is that it’s similar to J2EE and the portal. When you’re building a Web app with Struts, it’s very flexible and not targeted at somebody who would declaratively build things. But if you look at a portal framework, it becomes completely data-driven. What we see here is SIs [system integrators] taking our technology, building templatized business processes, and building wizards for people to be able to go and change them. It’s going to be a two-step process. First you need to have the layer underneath get baked and become more mature. I think it’s a couple of years before we can deliver the Holy Grail of having more parametric processes that nontechnical people can change and configure more easily.

Daring Fireball writes:

The user experience limitations of a web app are glaringly obvious. They simply don’t look or act like normal desktop apps. The browser in which they’re running — that’s a normal app. But the web apps running within the browser aren’t. They don’t have menu bars or keyboard shortcuts. (The browser itself does.) This isn’t about being “Mac-like” — it applies equally to Windows and open source desktop platforms. Instead of looking and feeling like real Mac/Windows/Linux desktop apps, web apps look and feel like web pages.

The persnickety little UI details I obsess over — these are nothing compared to the massive deficiencies of even the best web app. But most people don’t care, because web apps are just so damned easy to use. What’s interesting is that web apps are “easy” despite their glaring user experience limitations.

What they’ve got going for them in the ease-of-use department is that they don’t need to be installed, and they free you from worrying about where and how your data is stored. Exhibit A: web-based email apps. In terms of features, especially comfort features such as a polished UI, drag-and-drop, and a rich set of keyboard shortcuts, web-based email clients just can’t compare to desktop email clients.

But.

With web-based email, you can get your email from any browser on any computer on the Internet. “Installation” consists of typing a URL into the browser’s location field. The location field is the new command line.

Yahoo's purchase of Oddpost and IBM's acquisition of Alphablox has sparked off a discussion on rich web applications. Phil Wainewright points to a post by IBM insider Koranteng Ofosu-Amaah :

The "rich web application" strategy is a very powerful appproach to development - and one we first used when I was when working on Lotus K-station (the post-mortem on that is for another day). It entails complete leverage of the browser which, after all, is the ubiquitous client. If the browser adds features you inherit them automatically. A short description of what I think is needed:

A client side framework for managing 'widgets'; an 'widget' is construed as a parameterized blob that produces markup (either in-line html or iframe-based). The data model is pushed to the client, the page is stitched together on the client, augmented by chrome and a code layer handles drag and drop, preview mode, incremental rendering and client side caching etc.

The idea is to fetch an HTML skeleton, decide what content you need, fetch that as XML, and cache it wherever you get a chance. Render incrementally.

The pattern is simple:
Database <-> XML (Optional) <--> Javascript Object Bindings <--> UI Bindings (HTML) + UI management code

And: It's the Latency, stupid.

When dealing with distributed applications, it's the issue of latency that will determine which applications will rule. Users ultimately want applications that are 1. fast to load 2. capable and 3. intuitive. They want all these at the same time. This is where making increased use of the DOM should shine compared to most simple html based UIs. Of course, you have to work hard when writing DOM apps to figure out where in your architecture you can do things incrementally and where to cache. But that's what engineering is all about and how one would get paid.

In K-station the 'widget' was a portlet, your portal pages was the drawing canvas that the framework managed and you could navigate from page to page, incrementally building your page in memory and switch back and forth instantaneosuly. With client-side caching, all you're doing is the css display property. In the presentation editor, the analog of the widget was a drawing object (text, image, group etc). GMail and Oddpost follow the same pattern and it is the incremental rendering and caching that distinguishes them in their performance characteristics and makes them 'feel' like desktop apps.

The major missing infrastructure piece in rich web applications is going offline and synchronizing with good security.

WSJ writes that PC design is also moving to Asia in the form of ODMs (original design manufacturers):

These are full-service makers that design and build finished products that other companies can then brand as their own.

A growing percentage of products in the computer and electronics industries -- it's hard to know the exact amount -- are being designed as well as made by ODMs. The trend represents a new wrinkle in the developing global economy, and one more reason for American tech workers to be a little edgy about their future.

Much of this is happening on Taiwan. During the 1980s, the island became motherboard maker to the world. That's a big and important business, but not a particularly lucrative one; lots of people are able to take a computer company's motherboard specs and then mass produce the design.

So motherboard companies began adding in-house design staffs so they could offer more "value-added" services. After a while, they were doing all the motherboard design work themselves, and they soon took the next logical step: designing the entire computer. Lately, they have been branching out into new fields, like cameras and cellphones.

Adam Pick, who follows ODMs for the research outfit iSuppli, says that the ODM phenomenon is most advanced in the notebook computer market, with Taiwanese companies like Quanta Computer, Compal and Inventec designing and making the bulk of the world's machines.

While it varies from company to company, Mr. Pick says that typically, ODMs do the bulk of the design work on a product, with the client company perhaps making slight customizations of exterior features. That helps ensure that products look different in the marketplace, at least most of the time. It also allows computer companies to say that they help design the product themselves -- even though their ODMs are doing most of the heavy lifting.

Sometime ago, Dina Mehta and I had met a large Indian company who wanted to make their Intranet more effective, and making the various teams more productive. These notes, made by Dina, capture what would be the ideal information workspace:

We asked the question - what is the dream system you desire - and that was really interesting. What it revealed is the need is not as much for a Content Management System as much as it is for a system that allows them to dialogue and converse effortlessly and seamlessly, brainstorm on ideas and projects, in a manner that is as 'face-to-face' as possible. Here's the gist of what an employee told us :

I know X is not here in my office (in Mumbai) but in another city. I want to be able to talk to her, as if she's in the same room as me. I want to be able to feel all the nuances in talking with her - its got to be touchy-feely and not a cold email or a phone call where I know the time ticking away means my bottomline suffers.

Underlying what this employee told us is her desire for flow. Easy, hassle-free, inexpensive flow. Flow that allows a dialogue as if the other person is right there with her.

Incorporating :

Presence indicators

Communications system

Collaboration space

One of the key requirements - really a very simple one to have, but something so sorely left out in the current system, is a presence indicator. Much like in current IM systems - telling us who's available, who's logged in and therefore present in the office, who I can ping for a query, and ensuring that a response is received. In the case of his organisation, currently, they'd send an email, wait for a response, followed by more emails as reminders, and finally in sheer frustration, pick up the phone and make a call - which can be expensive if outstation (as is the case very often in their line of business) and does not always ensure that they will get a response - what if the person is away from the office?

Tied into this requirement for presence indicators is the need for 'real-time' 'live' communication. This is where voice applications, small cam shows, conferencing facilities would be useful. Skype with its conferencing facilities has really shown its possible to do this with terrific quality. Combine this with some of the 'soft profiles' that make a person far more approachable than just another colleague, like those on Ryze or Orkut.

And finally the need for collaboration spaces - where one can play around with Wikis and Blogs. Not having to rely on a whole host of asynchronous emails - or bothering to archive them systematically - these tools can do that automatically for you. And more food for thought pinging its way in through RSS in Newsreaders.

Picture this scenario - you have a project on and are racking your brains about how to approach it - you check your presence indicator - see who's available - ping them with a request for conferencing - hitch up the webcam, enable voice - and bingo - in minutes you have a virtual team ! Record the conversation, take notes on the wiki, synthesize it in a team blog which has comments enabled, feed in current thinking on the topic from your newsaggregator, and you have real flow. And, ridiculously easy group-forming to borrow a wonderful phrase from Clay Shirky.

Tomorrow: India Action: Create Contentrix