...
The Content Handler module receives data from Interface modules along with the content type of that data. Using this information it is expected to forward data to the an appropriate processing Processor module that can handle that data. It is also required to have functionality to allow processing Processor modules to be able to dynamically register and de-register their interest to data of particular content types.
...
The Content Handler module is [going to be] very light-weight. It's purpose, at an implementation level, is to:
- Provide generic interfaces to Interface modules for abstracting the operations that can be performed by Processor modules
- Provide functionality for Processor modules to dynamically register/deregister as handlers for specific content (MIME) types.
See the below interfaces; Processor modules can register handlers for specific content types during module startup (or whenever deemed appropriate by the module). The content handlers need to provide functionality to save and retrieve content. Interface handlers can simply then retrieve a registered instance based on the content type of the data they need to handle. The Content Handler module will provide a default handler in the case that there are no handlers registered for a requested type. Most likely this default handler will be the Unstructured Document handler. The module follows the prototype pattern for content handler instantiation. When registering a handler, a Processor module provides an instance of a handler. Then whenever the getContentHandler method is called, the Content Handler module will clone an instance of the handler for use by the caller.
...