Package org.moyoman.module

Provides classes for creating and administering modules.

See:
Description

Interface Summary

Component	This marker interface is implemented by Module and Helper.
ComponentType	Analogous to the Component interface, ComponentType is implemented by ModuleType and HelperType.
ModuleInterface	Both the Module abstract class and each module interface inherit this interface.

Class Summary

Mode	This class represents the different modes that the server can use.
ModeConfig	This class provides methods for configuring the mode information.
ModeConfigTool	This application provides the user with a user interface for editing the mode configuration files.
Module	The base class for all modules in the system.
ModuleConfig	Read and write configuration information related to modules.
ModuleConfigTool	This application provides the user with an interface for editing the module configuration files.
ModuleName	This class represents a module name, e.g, org.moyoman.module.shape.shape1.Shape1.
ModuleType	This class represents a module type, e.g, Shape.

Package org.moyoman.module Description

Provides classes for creating and administering modules. This is the heart of the Moyoman server program. Functionality is added to the system by adding modules. Each module that is added to the system extends the Module class in this package, and implements an interface in one of the subpackages.

For example, a developer adding a Shape module would extend the Module class, and implement the org.moyoman.module.shape.Shape interface. If the Shape interface already exists, then creating a new implementation is a simple matter of creating a unique package name under org.moyoman.module.shape, and putting the Java files under there. The only class in that package which should have any public methods is the one mentioned above which extends Module and implements Shape. It should not have any public methods in addition to the ones in Module and Shape, so that all Shape modules can be interchangeable. Once this is complete, it is up to the testing team to determine which Shape module is the recommended one. There is a recommended module for each mode. So, one module might be preferred for the BEST mode, and another one for the FAST mode, etc.

If no Shape interface exists, then the developer should propose one, which would be discussed by the Moyoman developer community and alternate proposals or suggestions made. Once a version of the Shape interface is approved, then implementation is straightforward as discussed above.

The reason that there may be competing implementations of a given interface is that even though the WHAT is well understood, the HOW may not be. Writing a good Shape module will most likely be very difficult. The Moyoman architecture is designed to allow multiple teams to investigate different approaches in parallel. On the other hand, it is unlikely that multiple implementations of simple modules such as Board or Group will be necessary.

It is probably a good idea to post a message before beginning work on a new module briefly stating which module you are implementing, and the basic approach that you will use. This can help prevent duplication of effort, and pair up people interesting in working on the same problem.

The implementation of the Board module might be a good example to look at if any of this is unclear.

Author:

David Weiss