Customized Software

1. The need to retain recognition for the component
2. The need to maintain control of the source and to allow for updates
3. The need to handle plug-ins that perform a subset of the operations (and thus are not a direct replacement) but that provide all of operations that a particular application may need.

For example, in the MPI specification, it is possible to implement faster versions of the collective operations by assuming (and hence requiring) that only contiguous data buffers will be used (rather than the more general datatypes supported by MPI). An application user may want to build a custom MPI implementation that makes use of such a specialized implementation of some of the MPI collective routines. On the other side, a developer that has produced such an implementation may want to provide the code, but needs to retain ownership and recognition and cannot simply donate the software to the MPI implementors.

This project seeks to develop a specification language and a web-based implementaiton that allows a user to build a custom version of a library or application. The available components advertise themselves as a web service, specifying the software that they interact with and the level of compatibility (see below).

Some of the items that a component specification may provide include

• Package that component is for (e.g., MPICH)
• Known version match (e.g., tested with 1.2.4 and 1.2.5)
• Known architecture match (e.g., IA32)
• Known system match (e.g., Linux 2.4)
• Component name (e.g., MPI_Allreduce). A hierarchical name may be used, such as MPICH:COLLECTIVE:ALLREDUCE.
• Testing method (e.g., which tests to run in the package's test suite to test correct installation).