Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

This page represented a proposed RoadMap to 2.0 from Tim Donohue. It still needs broader discussion/approval before adoption.
This proposal was initially discussed in the DSpace Developers Meeting on March 16, 2011. See the meeting notes for more info about initial discussion.

Overarching Goals / Priorities

The overarching, defining goals of this general 2.0 RoadMap are as follows:

  1. Simplify the process of installing & upgrading (make it easier for institutions to stay "up to date" with their installation)
    • As a subpoint, also make steps to simplify configuration/setup, so that more of it can be completed via an Admin User Interface
  2. Improve upon the ability to import / export data and generally make data more accessible/usable by external applications/systems (i.e. improve "integration points")
  3. Make steps to allow for decentralized support of add-ons, third-party user interfaces, etc. (i.e. make steps to no longer require that all DSpace modules/UIs need to be supported centrally by the Committers)
  4. Make steps to enable DSpace with Fedora Inside as an installation option

Proposed RoadMap to 2.0

Please note the the features listed under each release are only suggestions of priority! It may be that specific tasks/features will end up happening in either an earlier or later release, based on available developer/committer time.

DSpace 1.8.0 (Oct 2011)

The following modifications should be high priority for this release:

  1. Initial simplification of Installation/Upgrade processes (see DS-802)
  2. Refactoring & modularization, which may include taking initial steps detailed in the following proposals (Note: the implementation details of these proposals are obviously up for discussion):
    1. Begin to Restructure Trunk Projects and Asynchronous Release Process - with a goal of ensuring our various applications do not all need to be installed out of the box
    2. Begin Refactoring the DSpace Domain Model - with a goal of ensuring we begin to separate our data model from underlying data access services (will be necessary to help support move towards Fedora-Inside, while also potentially enabling use to expand support for additional databases, etc)
    3. Move towards more widespread usage of DSpace 2.0 Services (some examples in this proposal: Replace DSpace ConfigurationManager and PluginManager)
  3. Begin to Improve "Interoperability" / Integration points
    1. Release a beta version of REST API
    2. Potentially allow for AIP Transmission via SWORD?
  4. Also release features which just missed 1.7, but seem of high interest. Especially the following (this is not an exhaustive list!):
    1. Additional Curation Tasks?
    2. Configurable Reviewer Workflow - project that enhances Reviewer Workflow configurability that is orthogonal to Curation Tooling.
    3. Context-Guided Ingest?
    4. SWORD Client for DSpace? - of high interest if we wanted to enable AIP Transmission via SWORD
    5. Other features listed on DSpace Release 1.8.0 Notes

DSpace 1.9.0 (TBD - Oct 2012?)

The following modifications should be high priority for this release:

  1. Additional Refactoring & Modularization (especially in preparation for "DSpace with Fedora Inside"). This may include the following proposals (Note: the implementation details of these proposals are obviously up for discussion):
    1. Any refactoring that didn't happen in time for 1.8.0
    2. Refactor Packagers to support Chain of Command (if it doesn't make it in 1.8.0)
    3. Metadata For All - begin to enable metadata on all DSpace Objects
  2. Improvements / simplification of DSpace Configuration (perhaps even moving some configs to a DB). Minimally, this needs to simplify the 'dspace.cfg'.
  3. Change which Interfaces come "out-of-the-box", and allow others to be optionally installed at a later time (The following is only meant as an example.)
    1. Default install may only include: XMLUI, SOLR, possibly SWORD?
    2. Change LNI, OAI-PMH, REST and JSPUI to "optional".
      1. Potentially 'deprecate' support for LNI (or locate external, third-party support for it). Discuss whether any other Interfaces should be similarly deprecated (based on community-wide usage, etc).
    3. Encourage the community to develop / share / support their own third-party UIs (which potentially could communicate with DSpace via REST API, or via a refactored DSpace Domain Model API).
  4. Asynchronous Job Scheduler? (would replace the need to schedule jobs via 'cron' or similar)
  5. Any Features/Changes that just miss making it into 1.8.0
    1. Context Sensitive Help for XMLUI (@mire)

DSpace 2.0 (TBD - Oct 2013?)

  1. Support for DSpace with Fedora Inside (will likely require more Refactoring/Modularization to achieve)
  2. Any additional refactoring/changes that didn't happen in time for 1.9.0.
  • No labels

3 Comments

  1. Mark H. Wood

    Is there something wrong with cron? What would adding another scheduler to the system buy us?

    1. Tim Donohue

      Nothing in particular wrong with cron, other than it's not cross-platform (i.e. not on Windows, even there is a separate Windows Task Scheduler). The reason for the suggestion of a DSpace job scheduler is to allow for users to schedule ongoing tasks via Admin UI (e.g. Curation Tasks). It's yet another way to make DSpace slightly easier to use, and to not require as much System Administrator management/support to get up & running.

      Another way of saying this is: I believe it'd be nice if Repository Managers could more easily manage the schedule of when they'd like various Curation Tasks to run (e.g. virus scanning, various content reporting tasks, etc.) without requiring that they either (a) know 'cron', or (b) need to go through someone else who knows 'cron'.

      So, as we start to investigate allowing more DSpace configurations/settings to be set directly from an Admin UI, the scheduling of tasks from Admin UI is another option that we should investigate. That's not to say we couldn't still allow people to use cron if they wanted to.

      Obviously, this idea requires further investigation, especially around whether implementation can be done reasonably (without too much overhead and/or extra complexity).

      1. Mark Diggory

        A basic implementation already exists and works.   Albiet without administrative controls over the schedule implmented.  The project (and this would be excellent for GSoC) would be to create a series of interfaces (XMLUI) that would allow control over the scheduler,  the design requiremetns for these can be taken from other projects that utilize scheduling via Quatrz, for instance

        https://wiki.openmrs.org/display/docs/Quartz+Scheduler+User+Guide

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.