Page tree
Skip to end of metadata
Go to start of metadata

Design Direction Proposal to work on the elimination of configuration files in favor of storing configuration in database wherever possible.

Overview

Recently there has been a great deal of talk around bring large portions of the DSpace configuration under management in the Database. Recent work in last years GSoC community projects prototyped placing the InputForms.xml into the Database. Proposals for GSoC this year reflect an ongoing interest int his endeavor on files such as dspace.cfg.

This is a design direction proposal that we are trying to get away from more stuff hanging out in directories within the dspace installation. The focus should be on getting these files into the data model (submission, input-forms, config, etc) and persisted into the db/storage layer so they may be managed by the repo admins / users, not system admins/developers.

Proposed targets for Database Persistence:

  • Non-Dependency Injection / IoC properties in dspace.cfg
  • InputForms / Submission Workflow
  • ...

Other Related Discussions, Tasks and Projects

1 Comment

  1. This need not be a single project. Any self-contained subset of the configuration could be moved into the storage layer and admin. UI anytime someone has time to do the work. Subsets can also be moved as part of other work on the affected area. It's like converting to Services: if I see an opportunity I can just dive in and do that bit.

    Meanwhile, though, we may want to study the existing admin. UIs a bit and see if they're well structured for incremental extension.