...
| Excerpt |
|---|
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 Module name | Description/Comments | Source code |
|---|---|---|
dspace-api | DSpace API | |
dspace-xmlui | XMLUI (Manakin) | http://scm.dspace.org/svn/repo/dspace/trunk/dspace-xmlui  |
storage-api Yet | non existant module. Will constitute Constitute of DSpace 2 storage interfaces. Will be referenced from dspace-api (dspace-xmlui?). Depending on backporting strategy used, this module may also include additional storage related classes. Currently parts of it (interfaces) located at xmlui and other modules which will use new storage mechanism. | http://scm.dspace.org/svn/repo/ dspace2core/src/main/java/org/dspace/services (/mixins) |
storage-default legacy | Yet non existant module. Module will implement storage-api interfaces. Will probably contain classes from dspace-api, such as: DatabaseManager, TableRow, TableRowIterator, BitstreamStorageManager and other code. Some of the affected classes located at 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. | http://scm.dspace.org/svn/repo/modules/dspace-storage/trunk/ dspace-apiimpl/src/main/java/org/dspace/ storage |
Development plan
...
- Analysis of dspace-api
- Analysis of dspace-services module (http://scm.dspace.org/svn/repo/modules/dspace-services/trunk)Analysis of current situation in
- Better dspace-api (identifying storage related Java classes and references to them)
- Iterated code refactoring and development:
- Identify code fragments which potentialy constitute particular storage-service method in dspace-api
- Move these code fragments to storage-default module under particular storage-service interface method name
- Retain the relation of dspace-api with storage-default from newly created method perspective through use of storage-api interfaces and perform all neccesary tasks to ensure separated code interoperability
- Thorough testing of separation, whether the system work the same way it worked before backport (unit tests could be helpfull here)
- dspace-xmlui relation to storage-service interfaces
- ...
List of storage-api classes/methods
Classes and methods to be ported. List will evolve.
Interface/Class name | Method name | Description/Comments |
|---|---|---|
boolean exists(String entityId) | – | |
| StorageEntity getEntity(String entityId) | – |
| List<StorageEntity> getEntities(String location) | – |
| List<String> getEntityLocations(String entityId) | – |
String createEntity(StorageEntity storageEntity) | – | |
| boolean deleteEntity(String entityId) | – |
| void saveMetaProperties(String entityId, StorageProperty... properties) | – |
| void removeMetaProperties(String entityId, String... names) | – |
| boolean addEntityLocation(String entityId, String location) | – |
| void removeEntityLocation(String entityId, String location) | – |
List<StorageVersion> getVersions(String reference) | – | |
| StorageEntity getVersion(String reference, String versionName) | – |
String copyEntity(String reference, String path, boolean recursive, String newName) | – | |
StorageEntity restoreVersion(String reference, String versionName, String label) | – | |
| void setVersionLabel(String reference, String versionName, String label) | – |
– | Is this one needed? | |
– | Is this one needed? | |
Any others? |
|
|
- 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