Context Toolkit Installation Guide

This document contains the installation guide for the Context Toolkit. This is just one piece of the user's guide. There are two other pieces, including a tutorial and source code documentation. The installation guide contains information on how to install the Context Toolkit and get a simple application up and running.

Installation (updated 09/11/00)

  1. Download and install the Java Development Kit into a directory <JDK>. I recommend using JDK 1.2.2 or higher, although I have used JDK 1.1 in the past. I am currently using JDK 1.3. When/if asked if you want to install the Java Runtime Environment, select this option.
  2. Download the context.zip file. For now, to get the location of this file, you must contact anind@cc.gatech.edu.
  3. Unzip the context.zip file into a directory <DIRECTORY>.
  4. Add the <DIRECTORY> directory to your CLASSPATH
  5. Move the jar files in <DIRECTORY>/context/jars to <JDK>/jre/lib/ext. The jar files are 3rd party jar files. gwe.jar is from GWE Technologies and provides the JDBC access to the MySQL database. aelfred.jar is from Microstar Software and provides XML decoding. sax.jar is from Megginson Technologies and provides support for multiple XML decoders. ntp.jar is from Limburgs Universitair Centrum and provides support for talking to a Network Time Protocol server. To retrieve ntp.jar, unzip the Ntp.zip file. All of the jar files are free to use and redistribute.
  6. Add these jar files to your CLASSPATH explicitly. Not sure why this step is needed - jar files in <JDK>/jre/lib/ext are supposed to be placed automatically in your classpath, but it doesn't seem to work anymore.
  7. Modify the name of the Network Time Protocol server used in context.arch.widget.OffsetThread to a local NTP server. Currently, the server is set to ntp1.gatech.edu. You'll get a faster response, if you use an NTP server that is fewer network hops from your installation location.

Running a Simple Application (updated 09/12/00)

To run this application, you don't need to have a networked machine. A network is only required if you want to run the components on different machines, or if you set the widget to use database storage (change false to true in the widget invocation below)
  1. In one window, run the widget:
    1. To see the widget's parameter list: java context.arch.widget.WPersonNamePresence2
    2. Run the widget: java context.arch.widget.WPersonNamePresence2 test 5000 false
    3. The widget should load a GUI (6 buttons)
  2. In another window, run the application:
    1. SimpleApp.class is missing from the distribution. You can download it here and put it in context/apps/PersonPresenceApp or compile SimpleApp.java directly.
    2. To see the application's parameter list: java context.apps.PersonPresenceApp.SimpleApp
    3. Run the application: java context.apps.PersonPresenceApp.SimpleApp test 5001 127.0.0.1 5000
    4. The application will subscribe to the widget
  3. Now interact with the widget's GUI, pressing buttons to simulate the coming and going of various people. On the application window, you should see print statements showing the results of the subscription callbacks.

Other Applications

Now, I suggest looking at the other applications in the context.apps.PersonPresenceApp package. These applications demonstrate how to use various features of the Context Toolkit. You probably can't actually run these applications directly, because the widgets they communicate with, require a Java iButton as the sensor. They can be modifed quite easily to run with the WPersonNamePresence2 widget that uses a GUI as a sensor, but this hasn't been done yet. You would just have to modify the widget id that the applications are currently using to match that of WPersonNamePresence2. Here are some features of the other applications: Finally, take a look at the context.apps.InOutBoard package. This contains the In Out Board application. It is actually much less complex than PersonPresenceApp, in terms of the communication it has with a widget, but it is a more realistic application. We have been running a version of this application for over 2 years. It, too, should be easy to modify to work with the WPersonNamePresence2 widget class.

iButton installation (updated 09/11/00)

If you want to run the other applications, you need to either modify them to work with the WPersonNamePresence2 widget (it uses a GUI as a sensor, rather than an iButton) or buy some iButton hardware and install the iButton software. Here are some instructions to do the latter:
  1. Buy a Java-Powered iButton and a Serial (or Parallel) Connectivity Pack from Dallas Semiconductor's iButton site
  2. Download and install the IDE for the Java-Powered iButton. I had a non-obvious problem when I installed this new IDE, whose solution I later found in the FAQ. If you're using JDK 1.2.2 or higher (anything that automatically uses HotSpot), and you want to use HotSpot, you need to edit your opencard.properties file. This file should be in your <JDK>/jre/lib directory. Remove the "_LEGACY" from each uncommented line in the file. If you'd prefer not to use HotSpot, leave the file as is, but you need to run java with the "-classic" flag. See the iB-IDE FAQ for more information on this.
  3. Run the test program we provide: java context.arch.generator.TestIButton
    1. As you dock and remove your iButton, the test program will print out the id of the iButton
  4. The widgets and applications that make use of the iButton should all work now

MySQL installation

If you want to build any kind of complex application, you almost for sure require context storage. Unfortunately, the only storage mechanism we provide makes use of the MySQL database. You can either provide your own implementation of context storage (as it was made to be easily pluggable into the Widget architecture) or you can set up your own MySQL installation. To do the latter:
  1. Download and install the MySQL database. It is free for almost all uses. It is available for many operating systems.
  2. Follow the installation directions, and create a user account and database
  3. You will then need to modify and recompile the context.arch.storage.StorageObject class. You will need to redefine the following constants:
    1. SERVER to be the name of the machine you are running MySQL on
    2. PORT to be the port number you are running the MySQL daemon on
    3. USER to be the user account you are using for your context work
    4. PASSWORD to be the password for this user account (Yes, this is not a secure method for sending your password!)
  4. The widgets and applications that make use of context storage should all work now
  5. To run a widget so that it uses storage, don't pass in a value for the storageFlag parameter, or pass in true. This will tell the widget to use the default storage mechanism.
  6. Currently, the default storage mechanism is set to write to the database every time it receives 2 pieces of information from its sensor. To modify this flushing condition, edit context.arch.storage.VectorStorage (the default storage mechanism implementation):
    1. To change the number of pieces of information to be received between flushing, change the value of DEFAULT_FLUSH_CONDITION
    2. To change the flushing condition to be time based, rather than data-based (i.e. flush every x milliseconds), change the value of DEFAULT_FLUSH_TYPE from DATA to TIME, and change the value of DEFAULT_FLUSH_CONDITION to be the number of milliseconds desired between flushes

Back to the User Guide


Context Toolkit Home
Last Modified: February 29, 2000
Comments to: anind@cc.gatech.edu