
Diskster consists of 5 Java packages, FM (runs on the file manager), DT 
(runs on the desktop computer), HH (runs on the handheld device or Sun's
wireless emulator), FS (runs on the file servers exporting disk space),
and Proxy (runs on the machine that proxies for the handheld).

1.	Compiling the packages

Each package's source file are stored in a directory of the same name.
DT, FS, FM and Proxy may be compiled using the Makefile in their respective 
directories. FM and Proxy compile as Java servlets, and require the javax
directory (Sun's Java servlet files) in the parent directory of the 
package. DT uses the BouncyCastle cryptography API and requires the org 
and java directories containing the BouncyCastle files in the parent 
directory of the DT package.

The HH package can be compiled using either Sun's wireless toolkit (available
from wireless.java.sun.com) or using Sun's SunOne studio. (It might be
possible to compile using third party compiler tools like CodeWarrior from 
Metrowerks.) I used Sun's wireless toolkit. The BouncyCastle cryptography
API files are included in the HH directory. I have trimmed (removed files)
all the BouncyCastle files not required by HH so that the size of 
the HH jar file is under 50 KB (actually it is around 33 KB). 50 KB is usually
the maximum size of a midlet permitted by handheld device manufacturers.
The class files and the jar file can be created using the wireless toolkit.
Sun's wireless toolkit includes KToolBar, which is a simple IDE that has options
to compile or run midlet packages.

2.	Executing the programs

DT.jar, FS.jar, FM.jar, Proxy.jar, HH.jar are executable jar files
One can execute the class files directly or can use jar files.

To make the jar files, I first compiled the java source files as describe above.
Then, on a linux machine, I executed the following command,

java -cvf PACKAGE_NAME.jar PACKAGE_NAME/*.class

where PACKAGE_NAME is the name of the package to jar.

DT.jar and FS.jar are regular Java jar files and can be executed with
the commands

java -classpath DT.jar DT.DeskTop
java -classpath FS.jar FS.FileServer

where the jar files are in the current directory. (We do not need the 
Java source files if we want to simply execute the jar files.)

Instead of executing the jar files, one can also execute the class
file directly. The general rule to execute a Java class that is part of 
a package is to use the command 

java PACKAGE_NAME.DRIVER_CLASS

where DRIVER_CLASS is the name of the Java class file that has the 
main() method.

If FM uses a self-signed certificate, the certificate must be imported
as a trusted certificate by machines running the DT and Proxy. I successfully 
followed the directions given at
http://www.infosys.com/knowledge_capital/thought-papers/usingHTTPwith_java.pdf
to import FM's certificate on a windows desktop. It is similarly possible
to import FM's certificate on a linux or solaris desktop.

FM.jar and Proxy.jar require a servlet server to execute. I used the
Tomcat server as the servlet server. To generate the FM's self-signed 
certificate and enable SSL support on the Tomcat server, I followed directions 
from 
http://java.sun.com/webservices/docs/1.0/tutorial/doc/WebAppSecurity6.html.

The Tomcat servers (one for FM and one for Proxy) must be configured to load 
FM package classes (or the FM.jar file) and the Proxy classes (or the Proxy.jar
file). I found the instructions at 

http://www.moreservlets.com/Using-Tomcat-4.html

very useful to run my servlets on the Tomcat servers.

The driver class (having the init() method) for FM is called FM
and the driver class for Proxy is called Proxy. Hence any URL
used to access the FM servlet should end with FM.FM and any URL
used to access the Proxy servlet should end with Proxy.Proxy.

Running the HH midlet on Sun's wireless emulator is easier than
running the FM or Proxy servlets on the Tomcat server. Sun's wireless
toolkit includes a KToolBar which is an IDE that has an option to 
run a midlet. Again, like the other packages, the driver class (having
the startApp() method) for the HH is called HH. Hence, any reference
to the midlet in the configuration of the KToolBar must say HH.HH.
There is a lot of documentation at wireless.java.sun.com for using
Sun's wireless toolkit to compile and run midlets. I used instructions
from Sun's website that can be found at 

http://wireless.java.sun.com/midp/articles/https/

to import FM's self-signed certificate as a trusted certificate on 
the wireless emulator toolkit.

I did not try the HH midlet on an actual cell phone. But it should be
possible to download and run the HH.jar file on a MIDP 2.0 enabled
cell phone. In addition to the HH.jar file, the cell phone will require
the Java Application Descriptor file, HH.jad and the manifest file, 
MANIFEST.MF, both are which can be created using the wireless toolkit.
HH.jad and MANIFEST.MF contain information about the HH midlet. I am not 
sure if the cell phone would provide a means (maybe through a web browser)
to import the FM's self-signed certificate as a trusted certificate. 
If the cell phone does not support importing a self-signed certificate,
we would have to use a certificate signed by a well know Certificate 
Authority (CA).

