Page History

...

[summary of goal]  There will obviously be limitations to what DSpace can and should do, so we need to have ways to support plugins/addons/extensions to that core functionality. Not all users of DSpace will need to achieve the same set of Use Cases, so we will need to define which are "core" and which would be better implemented as plugins/extensions (either centrally supported or third-party supported).

• Action 3A: (Streamline the core functionality, and provide a better "plugin" model for third-party plugins)
• Action 3B:
• Identify minimum set of functionality/features for 'IR-core' and refactor codebase to provide this. This core may not be functional as-is, since it may require plugins that aren't extensions (e.g. authN)
• Action 3B: Define a family of specifications/interfaces/tooling for 'implementation' plugins (like authN, storage, persistent ID services, etc).
• Action 3C: Define a family of specifications/interfaces for functional extensions to 'IR-core' ( working title: 'modules'), and refactor existing bundled code to conform to new model (if appropriate/cost-effective). 
• Action 3D: Provide infrastructure/tools for a module registry, where users can discover, and install modular extensions. Likely include both modules maintained by committers and community contributions.
• Action 3E: Devise a flexible but rigorous system of versioning all components (core, module, etc) where compatibility requirements can be checked/enforced by the build/deploy tools.
• Action 3F: Define and expose new interfaces (in 'IR-core' and possibly modules) to allow local customized code to run: 'integration points'.
• Action 3G: (Highly dependent on UI architectural work) Provide a user-discoverable registry/library of user interface templates (working title: 'themes'), that can be installed and adapted for local use. 

Goal 4: DSpace will be designed in such a way that it can be easily/quickly configured to integrate with new & future tools/services in the larger digital scholarship "ecosystem"

...