...
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. Subject to change. (Update: heavily refactored - moved from mixin solution to services concept) | http://scm.dspace.org/svn/repo/modules/dspace-storage/trunk/api/ |
storage-legacy | 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. (Update: since dspace-storage-api has been refactored and instead of mixin solution services way there chosen, this class or its modifications most likely will not be used.) |
...
Recommended changes to "existing" DSpace 2 storage-api:
"StorageProperty\[\] parameters should be dropped from the StorageEntity object all together." \ [DSPACE:2\]Wiki Markup "StorageProperty service methods for performing CRUD operations on Storage properties be maintained on a separate mixin interface." \ [DSPACE:2\]Wiki Markup "StorageRelation be removed from the object model and relations be captured only by attaching StorageEntities as "values" of StorageProperties." \ [DSPACE:2\]Wiki Markup - "... remove methods like getEnititesAtLocation("/community/collection") and would recommend the use of the Search API instead for the retrieval..."
- "Mapping a prefix to the provider should warrant needing a separate interface to be implemented. That could just be part of assigning the StorageService to the map it is cached in the ProvidedStorageService."
Update: after long discussions on how dspace-storage-api should look like, it was chosen to refactor whole api and move from mixin solution to services concept, thus some of initial proposals on api changes does not reflect in current model implementation.
...
Provided api will evolve further, but most likely that basic components provided in diagram won't change or only minor changes can be introduced. Where are plans on incorporating interfaces for indexing, search and ContentModel services.
Backporting strategies
There are different ways to backport dspace-storage into DSpace 1.x, some of these are described here.
Since DSpace 1.x model data is mainly accessed through particular DSpace 1.x entities (Community, Collection, Item, Bundle, Bitstream, BitstreamFormat), new storage mechanism somehow will interact with them. There was discussions (during IRC meetings) on whether DSpaceObjects should be backed by dspace-storage or is it something what should be "covered over" by dspace-storage.
...
Elements in red are being implemented.
Update: since dspace-storage-api was moved from mixin solution to services, class ProvidedStorageService is replaced with EntityStorageService, PropertyStorageService and BinaryStorageService.
...