Recently I happened upon a blog site that had a discussion of one of my previous articles, one in which I proposed a need for a new "browser." The discussion was very interesting, but it was obvious to me I had not been clear about what I was asking for. Some of the folks on the board suggested that we could do what I wanted using Swing. Others realized that that required an installed or installable software distribution, and fixed on things like the Ruby language as a different approach. While all of these ideas had some merit, they didn't capture the true essence of what I think we need.

The browser, which is primarily IE and Firefox, represents widely successful and freely distributed software that render a platform-independent language (HTML) into information displayed according to the GUI elements of the underlying operating system. What the browser is not good at is serving as the basis for a real application. HTML has only limited control over the appearance of the browser; it's a synchronous request response model and it was really geared toward presenting content, not controlling the application. I applaud the heroic measures that have been taken to fit the round peg of applications into the square hole of content, but at best it works poorly and inconsistently.

I think we need a new paradigm for application delivery. Obviously, we need to be able to send our application over the Internet. First, we need an asynchronous, bi-directional secured protocol to provide the application to the user. What's sent over that protocol should be presentation elements, minimal presentation logic (such as phone number format validations), and the data that populates the view the user sees.

Unlike HTML, the application definitions should not have to be sent repeatedly in order to update the display when data is changed. Yes, you can do some of this with HTML and AJAX right now, and that's a good start; it's just not good enough. We need the description of the application to be independent of the implementation of the application so that it isn't just Java programmers, or PERL programmers, or .NET programmers who can develop an application. Yes, that's a break from the current paradigm, but that's what we need.

There was talk a while back of Microsoft taking an approach to the Windows GUI that had the application interface sent via an XML-based language. This was a great idea, and I hope it does eventually make it into the mix. An application sent over the Internet should behave and appear no different from an application that exists natively on a user's machine.

To do this, either the OS shell or another application (aka - the new browser) should be able to receive the application definition and render the application in a manner consistent with the look and feel of the underlying computer operating system. On a Mac, it should look like a Mac. On Windows, it should look like Windows. On Linux, it should look like Linux (pick your shell flavor). X-Windows was a concept that had a lot of this built into it, but it's too bulky, has too much of a least common denominator approach, and doesn't travel well over the Internet.

Obviously we'd need tools for developing the GUI, and tying the data elements and business logic to the presentation logic. Fortunately, defining a GUI is something we have 20 years of experience in, so the tools can be adapted rather than created from scratch. We'd also probably need a translation layer that would allow existing applications to be repurposed.

Finally, this technology needs to be vendor, platform, language, and implementation independent. To be successful, it needs a standards body champion, vendor buy in, and user participation. That's a lot to ask for, but we've seen it happen in the past. To all the guys on that blog, thanks for reading and all the comments.