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.)
• 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

...