MDS RELEASE NOTES This implementation of MDS is based on the idea that there is no separate module installation process. Instead, MDS interacts with modules as follows: - Each module bundle contains a resource which is simply an MDS database containing the records specific to that module. - Placing a module bundle into the designated path makes that module eligible to be registered with MDS. - Clients which utilize MDS will, when initializing MDS and then periodically thereafter, scan the module path and dynamically update the MDS database entries to reflect added, removed, or changed modules. The scanning of the module path is done implicitly within MDS API functions. DETECTING CHANGED MODULES MDS uses the following algorithm to detect added, removed, or changed modules: 1. stat() the directory in which modules are located. If its modification time is no later than the last time a scan was performed, stop. 2. Read the contents of the module directory with readdir(). Build a list of the directory contents, including the modification time of each bundle as returned by stat(). 3. Remove all MDS records for modules which are no longer present, or which have changed since the last scan. 4. Insert MDS records for modules which are now present but not represented in the database, including those whose records were deleted in step 3. This strategy has several implications: - Changing the contents of a module bundle will not change the module directory's modification time, and so will not trigger an update of the database. To cause an update when modifying a module, that module must be removed from the directory and then its new version must be placed into the directory. - No single process which is a client of MDS will attempt a rescan more often than once per 10 seconds. This means that it might take up to 10 seconds for MDS to sync after a change occurs. - Since any MDS client process can initiate a rescan, but no two processes should be updating the database at the same time, we use a lock file in /var/tmp to ensure only one process is scanning at any one time. DEVIATIONS FROM THE SPEC In addition to those differences noted above, this MDS implementation deviates from the specification in the following ways: MDS_Initialize() As part of initiating a client's connection to MDS, this function creates the MDS databases (if needed) and rescans the module path. MDS_Install() This call is specified to create the MDS databases. Since it can only be called with an MDS_HANDLE obtained from a prior call to MDS_Initialize(), which already creates the databases implicitly, MDS_Install() does nothing and silently returns success in this implementation. MDS_Uninstall() This call is specified to delete the MDS databases. In this implementation, it does nothing and throws the error CSSM_ERRCODE_FUNCTION_NOT_IMPLEMENTED.