Analysis part:
- Analysis of dspace-api module
- Analysis of dspace-services module
- Deeper review of spring usage in DSpace
- Analysis of dspace-database module
- Analysis of dspace-storage-db-2.0.x module
- Analysis of AIP prototype
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
Creation of java documentation
...

Evolution of storage-api

Proposed changes to storage-api:

Wiki Markup
"StorageProperty\[\] parameters should be dropped from the StorageEntity object all together." \[2\]

Wiki Markup
"StorageProperty service methods for performing CRUD operations on Storage properties be maintained on a separate mixin interface." \[2\]

Wiki Markup
"StorageRelation be removed from the object model and relations be captured only by attaching StorageEntities as "values" of StorageProperties." \[2\]

"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."
"... remove methods like getEnititesAtLocation("/community/collection") and would recommend the use of the Search API instead for the retrieval..."

Backporting strategies

There are different ways to backport dspace-storage into DSpace 1.x, some of these are described here.

...

Backing DSpaceObjects by dspace-storage allows immediate effect since all current modules uses these entities. However, this approach also involves changing internals of these entities, which opens possibility to introduce bugs affecting everything. This way created storage-legacy module would probably have to overtake the most DSpaceObjects internals, which also quite is coupled with dspace-api.
DSpaceObjects "cover over" by dspace-storage, if correctly implemented, is a cleaner choice, since changes in dspace-api can be avoided. storage-legacy module in this case would act only as a shim, providing access to dspace-api through storage-api. Conceptually, such solution probably is bad (storage logics should reside in storage-legacy), however it is a good "temporary" measure helping in moving DSpace 1.x to using new storage mechanismapi.

Shim or "cover over" solution is chosen as backporting strategy. Diagram below describes it in more detail.

...

Elements in red are yet to be implemented.

Changes pending...