Page History

...

• Action 2A: Avoid duplicative functionality. 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, which should be resolved:
    
    • 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. Each of these duplicative functions would be considered in line with use cases or supportive of our goal for "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 (Handle system, DOI, etc.)
• Action 2B: Enhance communication and collaboration. In order to avoid duplicative effort / projects in the future, we need to enhance communication and collaboration between various developers, institutions and service providers, and communicate a common vision / roadmap for the platform.
  
  • As a part of this action, we will be developing and maintaining a Technical Roadmap for the DSpace software platform, detailing high priority development projects which can be "claimed" or shared by groups of developers, institutions or service providers
  • At the same time, we should recognize that ad-hoc or competitive work can also be beneficial. We should continue to encourage ad-hoc contributions, and even competitive contributions, but make it clear that we will actively discourage further unnecessary duplicative functionality to be added to the platform (see Action 2A for examples).
  • Develop a basic User Interface "style / layout guide". In order to ensure a consistent user experience across all pages/features within the User Interface, we should provide basic guidelines for layout an styling of common page elements, etc. Examples may include basic guidelines for how errors/warnings/notices should be displayed, what class(es) to use for types of buttons, etc.

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

...