Tim O'Reilly has made much of his Web2.0 vision and has started the conversation in terms of what we should be expecting in the future in terms of the Internet and the services it can deliver. Much of this assumes the humble browser is in a position to deliver this dream.

However, the current browser is feeling the strain. With the explosion of AJAX it is desperately under pressure and this once simple rendering tool is now being asked to be a full JavaScript/DHTML runtime. Throw up a simple AJAX application like GMail and watch the memory usage of FireFox shoot through the roof. The browser is coming to the end of its product life cycle. The time has come to rethink this architecture to enable it for the demands people will be placing on to it for Web2.0.

Let's take a run down at some of the changes that need to be done to take the browser to the next stage. These aren't superficial features, but core changes to allow the next generation of developers to produce the applications we are now beginning to demand.

• Browser - name change required. It is no longer browsing data. It is the new web-operating system. Should we call it WebTop?
• AJAX is a good first step but has major shortcomings. For example, the kill button for any AJAX application is the REFRESH button. Time for a proper network layer for the developer.
• Stop thinking of the world as pages. We've gone as far as we can with frames, iframes and layers. Time to rethink this approach.
• Secure Data Cache Layer. You can only do so much with a small client side JavaScript cookie. We need to be able to store data in a secure sandbox for faster access.
• Data Synchronization. The network isn't always there, and it won't be there for a good number of years yet. We need to be able to go offline and still be able to compose email with GMail for example. The layer should handle our synchronization when the network reappears.
• Richer Client Widgets. The browser has been stuck with the basic controls for far too long now. We need to raise the bar here and introduce richer lists, trees, input boxes, etc. Leaving it to Flash isn't acceptable.
• Local Hardware Knowledge. The next browser needs to be able to hook into the local hardware available. Be it a web-camera, pda, finger print reader, or even just a USB storage key it needs to be able to access this data in a secure manner.
• Digital Key Management. The browser needs to be able handle different users and be able to handle their digital keys/signatures painlessly.
• Plugin Management. FireFox has shown the power that plugins have, but ensuring the right plugin is available is troublesome. Plugins should be portable with the user not the browser.
• Embrace Web Services. There needs to be the ability to communicate with web-services outside of the host you are running from. Tools to better consume ReST, XML-RPC and SOAP calls needs to be available.

Naturally when you look at this list you start seeing that these aren't all new features, in fact between Java and Flash most of this is very achievable. However, both have failed to capture the masses. AJAX has proved that people demand simplicity, they will build the complexity themselves. Flash and Java requires too much development effort, where as AJAX is nothing more than a few API calls in a web page.

The time for the humble browser to step out of the shadows and become the new client for Web2.0 has come. We need to build this.