We faced several problems during the work with the "Distance Education over Internet"-project. This section describes the problems we had with implementation of scripts/applets as well as the problems with the software/applications used for implementations and execution of the programs. Problems we had with deciding what methods and approaches to be used are described in the Development document but some of them is also discussed in this chapter, the choices we made depending on technical problems are also discussed from a technical point of view here.
The types of problem are divided into these areas:
The problems we faced when implementing JavaScripts did depend on bugs in the JavaScript language. Certain functions as onLoad did not work the way that they were supposed to at least not according to the books about JavaScript that we used. [bockerna.]. The most probable reason for this is that JavaScript is new and there are a many different versions, the bugs should probably not be a problem in the future, as there are quite a lot of persons working with fixing up these details. Anyway, these bugs put limits to some developments, but everything was solved by a bit more of work.
First of all, we had very little former knowledge of how to program in Perl. Perl is a high level programming language with many built-in functions of which many do not have any similar functions in "classical" programming languages such as C/C++ and Pascal. Most of the functions provided in "classical" programming languages do on the other hand have similarities in Perl. As we knew how to program in the "classical" way, most of the PerlScripts that we have developed consists of a lot of less intelligent (in Perl's point of view) implementations. Anyway, as we improved along the development of the project so did our Perl scripts. But still it was hard, particularly due to the difficulty of finding good information about programming in Perl.
Another problem was that we did not have any decent application for developing and testing PerlScripts. The programs used for implementation were Emacs, Microsoft Notebook and Microsoft Word Pad. The program used for testing was on UNIX the ordinary program for running Perl files that comes with the most UNIX systems and on Windows95, WinPerl Version Beta.3.
2. Problems with having the server accept and run PerlScripts
It was particularly two things that we had problems with. Even though these problems can be considered quite small, we sometimes spent hours trying to solve them, especially in the beginning, before we got a good idea of why they occurred and how they should be solved.
If a PerlScript should return anything understandable for the browser a special command must first of all be written on STDOUT. We knew from previous courses that the special command line should look like this:
When a Perl program is executed by a user logged in on a server, the perl compiler built in into UNIX know where to search for the Perl compiler to execute the program (given in some path in the users settings). The difference when a PerlScript is to be executed by a call from a browser, is that the server does not know where the Perl compiler is located, as there is no path set indicating it. Therefore in all PerlScripts, the path to the Perl compiler is set in the header of the script. The server does then search for the compiler when a browser calls the script (a path could for example look like this: #!/usr/local/bin/perl).
The problem we had was that if there is a return sign "/r" after the given path in the header of the document, the server consider the document errorneous and therefore returns an error message (HTML page) to the calling browser. If we developed or edited a PerlScript in Microsoft Notebook or Microsoft WordPad then some new line characters would be missing in the header of the PerlScript on the server, as Windows95 uses the return sign "/r" (actually WordPad do use them both, which always does not help anyway) and UNIX uses the newline sign "/n" to declare a new line in a program. The solution to this is to use WordPad in Windows95 and then paste two or more newline signs (taken from a document written in an UNIX editor and opened up in Notepad) into the head of the document after the path line. This problem does only apply to the path line of a Perl document, and the body can be filled up with "/r" signs without affecting the execution of the program, as the Perl compiler itself understand them both.
So even if we had a PerlScript executing without complaints when we tested it on the server, later on we could find that the same PerlScript would not be accepted by the server as a correct PerlScript when executing it from a browser.
3. Problems with trimming of variables
When reading a line from a file in Perl the new line character of the line read comes along with the line. If the line is to be used in a check against, for example a variable that does not have a new line character at the end, the check will return false even if the line and the variable were equal except for the new line character at the end of the line. In the PerlScripts used in the project quite a lot checks similar to the one described above are performed. What is needed is therefore a possibility to remove new line characters, and often white space characters of any kind too.
Perl has two different built in functions that easily (without a lot of computer calculations) removes characters from ends of variables/lines. These are chop and chomp. Chop just cuts of the last character of the variable/line and chomp cuts of the last characters of a line that corresponds to the Perl variable $/, which can be set to different values. The problem for us was that we wanted to have the possibility to cut of every end of line consisting of no visible signs (i.e. we wanted to cut off all white spaces, tabs and newlines) as these could also appear in lines read in from files. Obviously chop did not perform this action, but chomp could, if the Perl version on the server we used (ceibo.fing.edu.uy) had supported it. It did not.
In the beginning of the implementation we thought that chop would be sufficient, but after a while we found that it did not always work as we wanted. We then used another method, not as straightforward as chop, to get a satisfactory result. The method we used was split. If $userLine is the line read, then split(/\n/,$userLine) will return a line without the last new line, if there was a new line, otherwise nothing will be done. The split function can be used in different manners to remove white spaces and tabs too.
As we did not always know exactly when there would be a new line (or white spaces or tabs) at the end of a line read, and therefore not whether to use chop or split or none of them, we frankly used trial-and-error to find out.
Implementation of Java applets
Java is a relatively new programming language (introduced in 1996) and therefore there are some minor bugs inherited in Java. During the cause of the projects we succeeded with getting fatal errors, errors that did not depend on us but on Java itself, and such errors that the developers of Java are urgent to fix up. One of these problems we got in the sortVec method in the class CreateCourseDataLoader. Java did not like to much rearranging of an array, even though the code was totally correct. We adjusted all the affected methods without any harder efforts, but as always these kind of problems takes some time to discover. Looking at Java as a whole, these problems are not to annoying as they do not turn up very often.
2. Problems with initialization and start up of applets
In opposition from most applets ours do not start a process when loaded into the browser. Instead they are totally user driven, i.e. nothing happens if the user does not interact. This caused a minor problem when we were first designing the applets As most Java literature focus on the need of a start method in the applet we tried to put some of the initialization code there. This did work fine in the appletviewer, but when executing in Netscape the applet ran the whole start method and was then destroyed. Fortunately we soon realized that we did not need the start method. Instead all initialization code could just be put in the init method, this because an applet will be listening to user input even though the applet is not running (running should here be read in Java terminology) is never called.
3. Problems with sending Java POST calls from a LAN through a proxy/firewall
The first implementation of Java POST call we used were simply to open a socket to port 80 and write:
One solution may be to implement a special Socket class for the firewall using the proxy, this however is a project on its own.
4. POST & GET - which to choose?
To contact a PerlScript, HTML pages uses the method GET or the method POST. Generally GET is used for idempotent operations when calling a script with less than approximately 60 characters and POST is generally used for non-idempotent operations and when more information than approximately 60 characters are to be sent to a script. (To be a bit more exact the GET method can send about 1 Kb information, but that is for the whole URL, e.g. www.distancia.edu.uy/cgi-bin/checkPassword.perl?user=test&password=test&subject=TEST contains 84 characters = 84 * 8 bits = 0.67 Kb). Another (quite important) difference between the GET and POST methods is that in GET, data is passed in the environmental variable QUERY_STRING to the script and in POST, data is passed on STDIN.
We had problems with letting Java contact a script with the POST method if the user resides on LAN with all requests to port 80 (the HTTP port) having to pass through a proxy server. This could depend on some parameters in the users Java settings on the LAN that forbids Java applets to pass data on STDIN to a server.
Even though this problem possibly(?) could be solved by just asking the system administrator for the LAN to change the users settings, we thought it was the best to use as few POST requests as possible in the applets. We could not eliminate all of them though as we have to use the POST method when a new question page is to be created and when more than approximately two students are to be registered as these two types of calls consists of more than 60 characters to be sent.
For another discussion on the topic see Problems with sending Java POST calls from a LAN through a proxy/firewall above.
Applications used to run programs
Netscape Navigator/Communicator does not support the whole jdk 1.1, the latest version of Java (at the time of this writing), but it do support jdk 1.0.2 . There are quite some differences between jdk 1.0 and jdk 1.1, a lot of new methods have been added to jdk 1.1 and in the same manner there have been lot of deprecations (i.e. they are still supported, but they will be removed sooner or later) of old methods from jdk 1.0.2 As there are ways to get around the problem with Netscape Navigator/Communicator not supporting jdk 1.1 and because our intention is that the Distance Education over Internet package should form some kind of base for the continuation of the development of the Distance Education over Internet programs we did not consider using jdk 1.0.2 but decided to use jdk 1.1 instead. This should provide for further extension of the package.
Microsoft Internet Explorer seems to work quite satisfactory with jdk 1.1, but as there is a big fight between Sun (who are developing Java) and Microsoft (who are developing ActiveX) it is not sure that all Java programs will continue to work well in the future. As an example the Microsoft development of Java sdk (corresponding to SUN's jdk) implements some "bugs" which removes some of Java's platform independence. The reason for this is that Microsoft, who is the very dominant operating system provider with Windows95 and WindowsNT coming in the future does not want new operating system developers to gain shares on the operating system market. This would not be a big problem for other operating system developers if a lot of applications were written in Java as they can operate on all platforms.
It therefore seemed important that we could provide the Distance Education over Internet package for Netscape Navigator/Communicator to. This was done using a complementary batch file and a Plug-in in Navigator/Communicator, even though everything that "should" work using these solutions did not always work.
2. The complementary batch file for Netscape Navigator/Communicator
Netscape provides a complementary batch file that can be installed to give full support for jdk 1.1 in Navigator/Communicator. A problem with the batch file extension is that it confuses Navigator/Communicator when loading a new Java page after already having loaded one during the session. It can confuse Navigator/Communicator to that extent that the new Java page is not opened or that Netscape dies. Another problem is that if a Java page is opened in Navigator/Communicator and Navigator/Communicator is closed, Netscape dies and sometimes brings down the whole system with it. The latter problem can be solved by opening a pure HTML page that does not contain any Java applet, before closing down Communicator.
Due to these problems with the batch file, we decided to let the teachers use the Plug-in instead of the complementary batch file. Although we do provide HTML pages that does not use the Plug-in for the teachers that anyway wants to use Netscape Navigator/Communicator with the batch file installed or Microsoft Internet Explorer.
3. The Plug-in for Netscape Navigator/Communicator
Netscape has decided not to support Java in there coming basic versions of browsers (5.0), but instead use a Plug-in. The Plug-in then acts as a separate part and takes care of the Java executions. Netscape then do not have to integrate the Java virtual machine in their browsers and can just rely on the Plug-in. The Plug-in provided at the moment is a bit instable, so that sometimes when closing down Navigator/Communicator with a Java page opened, Netscape dies. This can be solved by opening a pure HTML page that does not contain any Java applet, before closing down Navigator/Communicator.
To let the Plug-in run a Java applet the HTML page containing the Applet must be modified. This can be done with a conversation program that converts the common HTML page to a Plug-in HTML page. See HTML for Plug-in constructor below.
We had a problem with the Plug-in locking itself while showing some window dialogues that Communicator, with the batch file installed, did not have any problems with. The dialogues could after some changes be used with the Plug-in without having the Plug-in locking itself. We did however never understand why it did work with some of the dialogues but not with others.
Applications used for implementation and debugging
We had some problems with implementing graphical components into out Java applets using Visual Café. When compiling an applet after a change, a adding or a removal of a component had been performed in Visual Café, the program did a reset to the old state it had before the change. This was quite annoying as we did not understand why it happened, especially as it did work in the older version of Visual Café (the preview) that we used in the beginning of the Java implementation. We found that it was due to that Visual Café the first time a graphical component is created also creates a method called addNotify, this method Visual Café then puts the graphical components in when it "thinks" that everything is "well", e.g. that the change, adding or removal of the component is to be permanent. This is also performed in a method called init, but the change is performed instantly when after a change. Then, for some reason when a change of the graphical environment is performed, Visual Café believes that the changes are not going to be permanent and therefore resets the graphical components in the init method to be the same as those in the addNotify method, in which method the changes never where committed.
The solution to this problem was to frankly remove the addNotify method after it first had been created from the applet, because Visual Café did not add a new addNotify after the first component had been created. This problem did not occur in all classes though, which can be considered a bit strange.
The addNotify method is normally used to notify a component about the components in a subclass of the component. It seemed to us that addNotify was mainly put in the applets for Visual Café's purposes.
2. Problems with Symantec JAR Packager Version 3.1.4
This is a program that comes with Symantec Visual Café PDE 2.5. When starting up the JAR Packager, Visual Café calculates the classes that should be packed into the JAR file. Before committing the packaging there is a possibility to remove those classes that the user think should not be packed into the JAR file. The problem arises if a class is removed and a JAR file is created. After such a removal, a new JAR packaging cannot be performed, because the entries (classes) to be packed can not be calculated. The solution of this problem is to close down Visual Café and restart the computer and open up Visual Café again. Then it is once again possible to create JAR files.
3. Problems with return signs in Microsoft Notepad and Microsoft WordPad
This is discussed under Different conventions
between UNIX and Windows95 for the new line sign in the Implementation
of PerlScripts section above.