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 statistics statistical engines (Solr vs Elastic Search)
  • Examples of necessary duplicative functionality (As each of these are in line with use cases or support flexibility of data import/export/storage)
    
    • supporting multiple database backends (PostgreSQlPostgreSQL, Oracle, etc)
    • supporting multiple interfaces for deposit (SWORD, REST, etc).
    • supporting multiple interfaces for export (OAI-PMH, REST, RDF, 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

...