Since content is allowed to be in many different forms it would be a lot of work to implement a content displayer on our own. The most general content displayer, for content in standard formats, is surely the Web browser. In addition, much of the available computerized learning material is already accessible via the Web, and it would simplify the development of content immensely if it can be developed directly for the Web. So we decided at an early stage in the design process that using a Web browser as content displayer solves the problems of displaying content in the most general way.
It is interesting to note that the current generation of browsers (Netscape Communicator version 6 and Microsoft Internet Explorer version 5) does support XML directly as a way of representing arbitrary information. This could be used to retrieve and parse the components and then just let the application access the information. It is questionable if it ever will be possible or even preferable to let a web-browser take over the application's job completely. This could in theory be done by a complicated Extensible Style Language (XSL) document. We have not thoroughly investigated whether this will be possible to do or not.
The problem of getting an application to work on different platforms cooperating with different browsers without rewriting the code is clearly solved by the Java programming language. This way, the application can actually be run both inside the browser, started from a website, or as a stand-alone application, remote-controlling a browser to display the content. Running as an applet undeniably increases the availability to users, as there is nothing to download and install.
Java is a very useful prototyping language for several reasons:
It is strictly object oriented.
Its memory management is simple for most simple cases.
There is an abundance of useful libraries, all automatically portable. Not least, the GUI libraries are cross-platform, which saves an enormous amount of work.
The choice of GUI library deserves a short discussion. In the Java environment there are two real possiblities: either you use the standard AWT-package, or you use the more recently developed JFC Swing package. We have choosen to work with the JFC Swing package, as it is, in comparison to AWT, better designed, more extensible and more flexible. It also solves the problem of keeping the design platform independent, as graphical components (buttons etc.) are drawn by the package, not delivered by the operating system, as is the case with AWT.
Java is also very well adjusted for usage together with XML, and there are several good parsers for XML written in Java. The reason for this is amongst other things the good Internet connectivity features, and the good international character set support of Java.
In short, the Java environment fitted the design goals very well. There are, of course, problems.
Firstly, as our application can run as an applet inside the browser, it is subject to applet security restrictions. These involve (taken from Frequently Asked Questions - Java Security):
In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host. In addition, applets loaded over the net are prevented from starting other programs on the client.
This means that our browser is not allowed to fetch components from anywhere on the Internet, only from the host where the applet is located. In addition, an editor used inside the browser would not be able to store the XML documents on the local harddisk. These restriction are not acceptable for anything else than a simplistic demonstration. There are several imaginable solutions to this problem:
Implement a proxy on the host where the applet is located, that can fetch components that the applet asks for.
Let the user run the applet from the local harddisk. Applets loaded this way are usually seen as trusted, and have no security restrictions.
None of these solutions are really satisfactory. The first will decrease speed and place a possibly heavy load on the server, while the second will mean a lot of hazzle for the user. We wanted to avoid that, and let the applet do the work all by itself.
The two browsers we have studied both have their own solutions to this problem. Both depend on the idea of digitally "signing" applets, and letting the user grant the applet privileges based on this signature.
Microsoft Internet Explorer uses a solution where the applet must be stored in a CAB archive and signed. This solution is unstandard and tied to the Windows platform, and has therefore been avoided for the prototyping stage.
Netscape Communicator uses a solution where the applet is stored in a JAR file and signed. The applet may then ask the user to grant it additional privileges. This is the solution we have used, as it tries to be cross-platform and standards-adhering. Fortunately, it would possible to use this solution in parallel to a Microsoft solution, as the impact on the code is minimal. This will possibly be done in the future, but for the moment, the security support only works with Netscape Communicator.
Finally, as browsers start to support Java 1.2, they will also start to support the Java 1.2 security model, which is also based on the idea of signing. Then we will have a less platform-dependent solution. At the time of designing the security handling code in Conzilla, we were using Java 1.1, and so this was not a possible path. When writing this document, Java 1.2 support is arriving, so it may be time to reinvestigate the issue.
The second problem is that the decision to use Swing to construct the GUI sadly limits us to newer versions of Netscape Communicator (exact version depending on the platform, but 4.5 should work) that include version 1.1.5 or later of the Java Development Kit.
So, our solution is not as platform independent as it might initially seem. We have hopes that future browsers will support the Open JVM Integration (OJI) API, which allows the Java virtual machine to be separated from the browser. Then it will probably be much easier for everyone to get hold of a compatible Java implementation.
There has been some discussion of simplifying the work for course designers and teachers by making the whole Java implementation JavaBeans compatible. This would mean that it would be possible to reuse the different Java objects in new environments such as a highly sophisticated Knowledge Patch construction environment, which our editor probably will never be and was not intended to be. But, as this seems to be relatively far into the future, the details of such a project remain vague at this point.