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.


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