RemoteGreenstoneServer and GLIApplet tasks

[ak19]

1. BUG: When the GLIapplet is used to build and preview a collection, and if the browser is then pointed elsewhere before the user returns to open the GLI applet and rebuilds the collection, then on clicking Preview the browser crashes.

Possible solution: Consider turning authentication task into an Action as well, by adding a ping command on the gliserver.pl end that is sent the username and password and which it can verify.

2. Applet: If either the gliserver.pl or authentication weren't provided, then pressing the Launch GLI button should once again ask for whichever piece of data was missing before GLI itself is launched.

3. When working with the GLI client against a remote GS server, files with French filenames are zipped in such a way that the original encoding is ruined. This means that the files the remote greenstone server receives have the wrong filenames and things go wrong from there (interlinking, file display names, missing images in htmls).

The solution maybe to check whether 7-zip can handle such filenames and if so, to consider moving to a Java-based solution that uses a 7-zip API.

[ak19]

Problem 3 above is solved. There were two issues identified on Linux, one of which was also there on Windows:

1. The issue they had in common was that the filename to was sent by GLI which was encoded in URL-encoded using Java and which presumed the filename's charset itself was in UTF8. However, the filename need not have been in UTF8 there was no matching url-decoding where the charset encoding could be specified. Fortunately, using Base64 encoding for those client-server interactions which were sensitive to filenames worked, in that encoding in Java and decoding in Perl operated together correctly and neither side was required to know the original charset encoding of the filename in order to do the Base64 encoding/decoding.

2. The issue identified on Linux was that the LANG env variable determined how zipping and unzipping was done using Java's zip tools. If the client and server had different values for LANG environment variables (or if this was not set on one side, while it was on the other) then zipping and unzipping produced different results and the original filenames would not be recovered. The solution was to let the client pass the LANG env var it used and for the server to set its LANG env to the same value for (un)zipping. This is OK since the server is not persistent (env vars get reset for each command the server executes) and since setting gliserver.pl's env vars does not make these leak into the rest of the server machine's context (to affect other programs run on the server). This solved the zipping of filenames containing special chars problems.

[kjdon]

Are any of these still valid??

[kjdon]

Anu, please check that these are all fixed