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.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »


If your work on DSpace involved any of the aspects below, please go to the relevant page to see what's going on, and add yourself to the list of interested parties! (Just add your name to the bottom of the page.) The goal of the DSpace Community Process is to establish an organizational process to the creation of new Proposals, Special topic Meetings, and their eventual "graduation" into DSpace Development Projects with scheduled integration timeframes to get into DSpace.

DSpace architecture white paper by RobertTansley - dspace-architecture-whitepaper.pdf\

Active Development Areas

Content by label

There is no content with the specified labels

Development Ideas

  • Page:
    Asynchronous Release —

    Asynchronous Release: Asynchronous Release is change in the DSpace release process and version numbering process on modules within the DSpace trunk to allow more flexibility adding prebuilt Addon modules into DSpace.
  • Page:
    CGIProposal — Configurable submission is one of only a few mechanisms in DSpace to assist the process of managing the metadata or other characteristics of items being ingested. Another tool is the Item template, which notably also is only configurable by collection. You can think of both of them in terms of a more general capability: using contextual information to streamline or automate the ingest. We can call this capability 'context-driven ingest' or perhaps 'context-assisted ingest'. Maybe the best description would be 'context-guided ingest' (CGI), since it suggests that context can provide relevant data, but need not rigidly determine all ingest properties.
  • Page:
    CurationTaskProposal — Create a standard way such tools and services could be integrated and used. The idea is to define an abstraction called a 'curation task' which operates at the Item level of the DSpace data model (but whose effects may very well be on individual bitstreams, or in the creation of new ones), and have some generic machinery for managing these tasks (running them, reporting on outcomes, etc).
  • Page:
    Database Persistence of Configuration State —

    Design Direction Proposal to work on the elimination of configuration files in favor of storing configuration in database wherever possible.
  • Page:
    Google Summer of Code 2008 Collection Workflow —

    In the current DSpace implementation, a workflow system is present that allows content submitters to ingest an item in the repository, that can be reviewed by simply accepting the submitted content, changing some of the submitted metadata or rejecting the item so it can be altered by the submitter. The current collection workflow system contains up to three steps for the submission of files. Except for the metadata changes, there are no possibilities for changing any of the submission content during the different steps of the workflow system.
  • Page:
    Metadata For All — This is based on Claudia's comments in the commiter list and the topic discussed elsewhere. Goals should be to expand on this and relate it to other projects/efforts. For instance, the async release proposal will now include establishing a true "API" for DSpace legacy objects and placing this in the "modules" directory where other projects can depend on it.
  • Page:
    Migrate Search and Browse to DSpace Discovery — This is a proposal to replace DSpace Search and Browse implementations completely with Solr
  • Page:
    Quartz for Asynchronous Scheduling Service — Using Quartz as a utility to manage asynchronous eventing in DSpace Services, we can setup a job scheduling environment in the DSpace web application that is consistent across platforms. Likewise, jobs can be managed such that they are persistent across tomcat sessions/restarts and give the Repo Admins the ability to manage the scheduling and de-scheduling of activities.
  • Page:
    Replace DSpace ConfigurationManager and PluginManager —

    Work on using the DSpace ServiceManagers ConfigurationService, Activators and Spring Configuration of Services to replace Configuration and Plugin Manager will finally and effectively encapsulate this functionality and remove a few sore spots in DSpace design where these "God Objects" interfere with our ability to make all parts of DSpace more easily replaceable and reconfigurable.
  • Page:
    Restructure Trunk Projects — This is a page of possible technical refactoring proposals for moving the trunk forward towards greater modularity and plug-ability.
  • Page:
    Upgrade Process Improvements — Improve upgrade Process with tools that complete and test upgrades.
  • Page:
    VOID LoD Endpoint Descriptor — EPrints supports VOID and LoD, So should we?

Legacy Idea Pool

Please work through these idea pages (children of the DevelopmentAreas page) and the rest of the hardcoded list below to consolidate the sections of this page into labels for above grouping.

Everything Under this Point needs to get reorganized and labeled. Use appropriate labels so that project proposals and active work areas show up where they should above.

From Scratchpad...

This page is intended for those of you doing DSpace work to provide a link to wiki pages you may have created to support your development work or to document your procedures.
Typically code will be stored in the "sandbox" area of the source tree.

Architecture

Work towards the DSpace 2.0 architecture: DSpace 2.0 Original Proposal

Storage refactoring

  • AssetStore - standards-based AIP storage layer for easier preservation
  • AipPrototype - (OBSOLETE - AIP Backup and Restore has replaced this). Please use prototype AIP implementation, above the asset store layer, for use on DSpace 1.4/1.5. Emphasis is on preservation and custody transfer of archived objects.
  • PluggableStorage - allow easier integration of different asset store backends. Prototypes within.
  • DAO Prototype - removes storage layer depedendent code from core classes. Should make it easier to port DSpace to other database platforms.

Modularity

User interface framework

Other aspects

Features/functionality

Metadata

Security

Preservation

  • DigitalPreservationToolsAndStrategies

  • [DSDOC:AIP Backup and Restore] - Based on the initial AipPrototype implementation (by Larry Stone), but only details with exporting/importing Archival Information Packages which describe the entire content hierarchy (Community/Collection/Item) within DSpace. Emphasis is on creating a better "backup" and restore solution, where an entire DSpace could be restored from a directory of these AIPs. [Released in DSpace 1.7.0 ]

Installation / Updates

  • InstallerPrototype - Prototype for a new "easy" installer, which will better automate the Installation/Upgrade processes for DSpace.

Other planned/possible work

  • Half-developed: Diagnostics servlet. A servlet that goes around and kicks the apps's tyres a bit on startup or on request. At the moment this just checks that the lucene index is present and unlocked. I'm hoping to extend this to checking that the db is present and correct, and maybe to check that the db and filesystem are in synch. No schema changes. Ojd20
  • Largely conceptual, some code snippets exist: Upgraded submission system (SubmissionSystem) - this is quite a big job so perhaps not for 1.3 but we'll see. RichardJones
  • Conceptual, shouldn't be too hard: Upgraded workflow system (WorkflowSystem) - not too big a job I don't think. Hardest part will almost certainly be the interface, as the options could be a little convoluted. RichardJones
  • Hierarchical collections as well as communities. Not implemented.
  • No labels

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