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.
In ICEBERG-v0, the Preference Registry not only stored user preference profiles, but also processed them. In ICEBERG-v1, the preference registry simply stores preference profiles. Its stores them in a distributed hashtable.
The preference profiles are generated by the preference manager (or some other GUI) and uploaded to the preference registry. The profiles are stored and retrieved based on the user's uniqueID.
Running the preference registry service and client
The service is run as part of iPOP:
java ninja2.core.vspace.vSpace ipop.cfg.demo1
The example configuration file is ipop.cfg.demo1.
The client for the preference registry service is either the Preference Manager or the test client "ScriptLoaderClient.java" run as a vSpace service:
java ninja2.core.vspace.vSpace pref-client.vspace.cfg
An example configuration file is pref-client.vspace.cfg. Make sure that the multicast address and port parameters, "stateTableName", and hashtableNode specifications match in the server and client vSpace files. The test preference profiles are hardcoded in the ScriptLoaderClient.java file. These test profiles only specify the default end-point for redirection. Search for the "createPref" calls in the file. The first argument gives the uniqueID of entity associated with the preference profile. The second argument gives the end-point information. The end-point information includes the "type", and address of the IAP. The second argument in the end-point constructor is the same as the third argument, except for a port number, which is ignored (some cleanup is required here :-).
See the preference manager documentation for instructions using it to upload preferences to the preference registry.