The Preference Registry

This document descibes the implementation and intended use of the Iceberg preference registry.

The preference registry is a repository of user preference profiles. The preferences refer to management of incoming communication. The profile serves to redirect or filter incoming communication based on several input parameters.

General description

The inputs to the preference registry (i.e., the members of the pref_req structure) are:

The output from the preference registry (pref_rep) has the following fields:

The preference profiles are generated by the preference manager (or some other GUI) and uploaded to the preference registry. The profiles are stored as TCL scripts (with if-then-else rules) and are interpreted to get at the preferred end-point of the user.

Currently, there are no mechanisms for the following:

Structure of the preference registry

The preference registry has a front-end that provides the interface for the outside world. The front-end uses a pool of Java-based TCL interpreters (Jacl interpreters -- see the Scriptics Java page). The front-end prepares the script for the interpreters, feeds it to them, and reads two variables set by the interpreters. The front-end also exports the interface to upload scripts into the preference registry.

The back-end uses files (or Steve Gribble's DDS - Distributed Data Structures) to store and retrieve preference profiles. Since the DDS is not part of the release, the back-end uses files for preference profile storage. For each user, there is a file <uid>.tcl containing the script.

Interface with the TCL preference profiles

The interface of the preference registry front-end with the stored TCL preference profiles

The script fed to the interpreter consists of two parts. The first is a bunch of variable assignments. The second is the user's preference profile itself.

The following variables are set before the user's preference profile:

The following variables are expected to be set by the user's TCL preference profile:

Interface to load scripts

The ScriptLoaderIF has a single routine "load(String dnStr, String script)" to upload scripts. The first argument "dnStr" gives the user's Iceberg unique-id in LDAP DN format. The second argument gives the TCL script itself.

The files

Running the preference registry and the script loader

Add the following line to the iSpace configuration file:
pref_reg.front_end use-files <pref-dir>

The first argument is just the string "use-files" indicating that the back-end of the preference registry should use files for storage. The second argument gives the directory in which the preference files are to be stored ot retrieved from.

The usage for the ScriptLoaderClient program is:

pref_reg.ScriptLoaderClient <pref-server> <email-id> <pref-file>
pref_reg.ScriptLoaderClient <pref-server> <num_email_ids> <pref-file>

In the first case, the given script is uploaded for the user identified by the given email-id (Iceberg unique-id). In the second case, the same script is uploaded for several dummy users: bi@domain for 0<i<num_email_ids. The second usage is for loading the preference registry with lot of dummy scripts to stress test it. In either case, if the pref-file is given as "-", STDIN is read instead of a file.

Bhaskaran Raman,
Last modified: Sun May 28 17:56:50 PDT 2000