Backport of DSpace 2 Storage Services API for DSpace 1.x
Student: Andrius Blažinskas
Mentor: Mark Diggory
Abstract
DSpace 2.0 storage mechanism provides convenient way to store DSpace contents in various storage solutions. It is based on set of interfaces for which various implementations are possible and some beta releases already exist (Jackrabbit, Fedora, etc). DSpace 2.0 is in its early stages of development and DSpace 1.x releases yet can not take advantage of this new mechanism. To fix this, it is necessary to port DSpace 2.0 storage interfaces to 1.x. I propose implementing this backport. – Andrius Blažinskas
Relevant modules/classes
Module/class name |
Description/Comments |
Source code |
|---|---|---|
dspace-api |
DSpace API |
|
dspace-xmlui |
XMLUI (Manakin) |
|
storage-api |
Constitute of DSpace 2 storage interfaces. Will be referenced from dspace-xmlui and other modules which will use new storage mechanism. |
http://scm.dspace.org/svn/repo/modules/dspace-storage/trunk/api/ |
storage-legacy |
Yet non existant module. Module will implement storage-api interfaces. Basically it will be the shim allowing modules to access DSpaceObjects (in dspace-api) using new storage-api. |
- |
dspace-services |
DSpace services module. DSpace services framework will be used to manage and gain access to storage-api implementations. |
|
ProvidedStorageService |
Class which acts as a mediator between caller and storage service implementations. However, its usage is questionable. |
Development plan
- Analysis of dspace-api
- Analysis of dspace-services module (http://scm.dspace.org/svn/repo/modules/dspace-services/trunk)
- Better dspace-api adaptation to changing needs:
- Evaluation and incorporation of changes described at https://wiki.duraspace.org/display/DSPACE/GSoC+Collaboration+Scratchpad
- Implementation of changes decided during commiter/student meetings
- Implementation of storage-legacy module
- dspace-xmlui relation to storage-api
- ...
Backporting strategies
Changes pending...
Proposed solution
One possible solution could be basically treating dspace-api module as a some sort of dspace-legacy implementation and dspace-legacy module itself will basically be a proxy to a dspace-api. It is advantageous that in this case other modules can be started being recoded to use storage-api without actually breaking whole system. Conceptually, such solution probably is bad, however it is a good "temporary" measure helping in moving DSpace to using storage-api.
Elements in red are yet to be implemented.
Evolution of storage-api
Changes pending...
References
GSOC 2010 proposal: Backport of DSpace 2 Storage Services API for DSpace 1.x, http://ab.labt.lt/gsoc/2010/dspace/proposal1.html
