8. Evolution and Prior Knowledge

In the future, the Service UI API can evolve in several different ways. Any party can define new role types and their meanings, new attribute classes, and new factory types. Any party can identify new toolkit types. For clients to be able to use these new types, the new types will need to be publicized. Before a client will be able to use a role, factory, or attribute type, that client's programmers must have had prior knowledge of the type.

Other than service-specific UI roles created under Jini Service APIs, new roles should come from the Service UI project at the Jini Community. Service providers should resist temptation to define new role types, as that complicates clients' jobs. Clients should be able to program to the interface (particular Jini Service APIs about which they have prior knowledge), rather than be forced to program to one or more implementations of that interface. Whether role types are being defined for particular Jini Service APIs, or globally for the Jini Service UI API, the preferred way to define the role interfaces is via the Jini Community Process.

As mentioned previously, new UI factory interface types should be defined with great care. The main justification for a new set of UI factory types is when new UI toolkits appear on the scene. The preferred way to define these interfaces is via the Jini Community Process. Similarly, although anyone can define new attribute types, the preferred way to define these types is through the Jini Community Process.

The Jini Community is the preferred process to define new role, factory, and attribute types because it is the best way to avoid a explosion of types. For example, if a certain attribute type is needed, and twenty different parties define basically the same attribute, but with twenty slightly different names and behaviors, and in twenty different packages, then clients wanting to use that kind of attribute would need to support all twenty variations. It would be far better if those twenty parties agreed on one attribute class. Enabling such collaborations is the Jini Community's main purpose. If twenty parties can agree upon one attribute class, then clients need to be aware of less information (one attribute class versus twenty), and the resulting client programs would likely work more reliably.