Page History
...
- Action 2A: To be "lean", the DSpace technology platform should avoid duplicative functionality except where necessary to meet use cases or achieve "flexibility" goals. Where unnecessary duplicative functionality already exists, the technology team should choose a "best option" solution, or propose building a new solution when a "best option" does not exist.
- Examples of unnecessary duplicative functionality
- maintaining multiple User Interfaces (JSPUI vs. XMLUI)
- maintaining multiple search/browse systems (Solr vs. Lucene)
- maintaining multiple built-in statistical engines (Solr vs Elastic Search)
- Examples of necessary duplicative functionality (As each . Each of these are duplicative functions would be considered in line with use cases or support supporting flexibility of data import/export/storage)
- supporting multiple database storage backends (PostgreSQL, Oracle, etc.)
- supporting multiple interfaces for deposit (SWORD, REST, etc.).
- supporting multiple interfaces for export (OAI-PMH, REST, RDF, etc.)
- supporting multiple external identifier schemes (Handles, DOI, etc.)
- Examples of unnecessary duplicative functionality
- Action 2B:
Goal 3: DSpace will include a "core" set of functionality that can be "extended" (think plugins) or have "hooks" (integration points) to complimentary services/tools
...
Overview
Content Tools