ICEsoft and Nexaweb wax where the browser wanes

Web browsers are wonderfully ubiquitous, but they offer substandard user interfaces because they do little to anticipate what the user might want. Most clicks require a round-trip to some distant server over a sometimes dodgy Internet. To make matters worse, the browser is beholden to the user, not the developer. It often prevents the server from doing much except displaying images, a bit of text, and maybe a fancy bit of multimedia -- and then, only if the right plug-in is installed.

Two companies, ICEsoft Technologies and Nexaweb, offer Web application developers another option. Both offer tools for building more fully powered Web clients that behave similar to browsers but offer developers deeper control. Their tools take radically different approaches and aren’t direct competitors, although they might be used to solve some of the same problems.

ICEsoft’s solution offers the developer the complete Java source code to a browser. Developers can clone Netscape with a few lines of code and then use the hooks to turn the right features on or off.

Nexaweb also offers a client, but it isn’t a full-fledged, standards-compliant browser. Instead, Nexaweb integrates a rich collection of widgets into a server, offering performance and behavior similar to traditional client/server applications. Both solutions are aimed at the Java developer community.

ICEbrowser SDK 6.0

To test ICEsoft’s version of the browser, I decided to build my own application, PeteZilla, that would offer a bit of digital rights management. This browser would display standard HTML but would disable caching, saving, or printing the file. Furthermore, it would use SSL encryption to secure the Web traffic and use standard authentication to control access to the server.

This browser was easy to create, in part because one of the dozen or so examples included with the ICEbrowser SDK accomplished most of it. Displaying HTML in a window requires approximately eight lines of code to create the frame and add the standard ICEsoft component to it. The code works with both the AWT (Abstract Window Toolkit) and Swing frameworks, making it easy to start up.

The toolkit comes with a fairly impressive collection of hooks that tap into most stages of the HTTP process. Authentication, for instance, generates events that can be caught and handled by an AuthenticationListener. If you want to add your own layer to handle the passwords and the interaction, it’s simple to hide this from the user. The events are the developer’s to grab, not the browser’s.

The rendering engine also generates a number of events as the document is parsed and the images are loaded. It’s easy, for instance, to include a status line that shows the progress toward building the entire display.

ICEsoft’s toolkit made building PeteZilla easy. Separating the content from the controls -- for example, leaving the content markup in HTML -- made it possible to delegate some of the work to Web designers so I could concentrate on coding the encryption to protect the content. Apple’s iTunes application is a great example of how a Web-browser model can be expanded with additional features without abandoning all the richness of existing tools.

Indeed, the biggest competitors to ICEsoft’s product may be open source projects such as KDE’s Konqueror and Mozilla’s Gecko. They cost nothing but do come with open source licenses that limit how you may use the result. They are also written in C, a limitation if you or your shop wants to use Java.