Gemini Object Model

The gemini object model is a cross platform component object model modelled after win32's IUnknown and COM. We do not support a C API to gemini at this time.

nsID

Like OSF's DCE, we use an "interface id" which is a unique identifer which names the interface. The nsID and be used as a key into a cross platform registry service to discover an implementation of an interface. Here is the declaration of nsID: On windows, the "uuidgen" program (provided with Visual C++) can be used to generate these identifiers.

nsISupports

This is the base class for all component objects. Not all objects are component objects; these rules apply to objects which expose an interface which is shared across dll/exe boundaries. Here is nsISupports: The semantics of this interface are identical to win32's "COM" IUnknown interface. In addition, the types are carefully mapped and the names are the same so that if necessary we can "flip a switch" and have the windows version (or any other platform that embraces COM) use the native COM IUnknown without source code modification.

Factory Procedures

Factory procedures use this design pattern The return value is a status value (see nsISupports.h for the legal return values); the first argument is a pointer to a cell which will hold the new instance pointer if the factory procedure succeeds. The second argument is a pointer to a containing component object that wishes to aggregate in the Foo object. This pointer will be null if no aggregation is requested. If the factory procedure cannot support aggregation of the Foo type then it fails and returns an error if aggregation is requested.

The following symbols are defined for standard error return values from QueryInterface and from factory procedures:

nsIFactory

Factory classes should eventually replace factory procedures for major classes. They provide an easy mechanism for placing code in DLLs. The nsIFactory class is as follows:
  This interface is again identical to the COM version. More on registering factories shortly.

Error Handling

Because no exceptions are returned, error handling is done in the traditional "error status value" method.

Cross Platform Registry

A cross platform registry was written for the SmartUpdate feature of Communicator. We will investigate it's usefulness for our purposes.

Library Management

NSPR 2.x provides the cross platform mechanism for loading and unloading libraries, and run time linking.