Date: Fri, 29 Mar 2024 10:19:18 -0400 (EDT) Message-ID: <1526975685.133.1711721958736@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_132_39466714.1711721958736" ------=_Part_132_39466714.1711721958736 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Considerable thought, discussion, design, prototyping, etc has focused o= n what a DSpace+2.0 asset store should look like. In particular, whether an= d how such an asset store should model archival information packages (AIPs)= in a more substantial manner than in the current architecture. This model = is conceived as a DSpace asset store API/interface. Of course one big advan= tage of such an interface is the ease of writing implementations for differ= ent storage systems (file-based, grid, etc) and plugging them into DSpace. = However, it should be noted that this benefit redounds to just having an in= terface, not having an AIP-aware one in particular.
Modeling an AIP asset store is very important (and hard), and it has pro= ven difficult to achieve consensus - and this has led to holding the benefi= ts of pluggable storage for DSpace hostage to agreement on an AIP model. Th= e work this page describes attempts to circumvent this problem by refactori= ng the existing asset storage system to drive a very thin API wedge between= the storage manager and the actual storage back-end. It conspicuously does= not attempt to model an AIP, only the low-level storage p= rimitives. If successful, it should make it far easier than it is today in = DSpace to attach different storage solutions. It should also feed the AIP a= sset store design process by providing insights into the powers and limits = of different storage systems.
I call this API a BitStore to emphasize that it is not = an AIP model, and have provided a refactored BitstreamStorageManage= r that utilizes this interface, rather than the direct calls it ha= d into the file-store or SRB store. In addition, I have provided 3 implemen= tations of the interface:
Another advantage of this approach is modularity: we will no longer have= to include all the code and required libraries for (e.g.) Storage Resource= Broker unless we actually want to use it. These storage modules also prese= nt some new use-cases for the Add-on mechanism work, since they are optiona= l modules, but not separate applications.
Detailed notes on using each store will follow. Note that this is protot= ype code, not production quality. Feedback welcome, includ= ing other possible store implementations (e.g. a RBDMS store). (See the Dis= cussion page for some thoughts on an RDBMS implementation.)
org/dsp= ace/storage/bitstore
org/dsp= ace/storage/bitstore/impl
http://= jets3t.s3.amazonaws.com/index.html
dspace/= lib
dspace.= cfg
assetstore.<n>=3D<prefix>:<config>
bitstore.<prefix>.class=3D<fqcn>
org.dsp= ace.storage.bitstore.impl.DSBitStore
assetst= ore.dir=3D
dspace.= cfg
$\{dspa= ce.dir\}/config/s3.properties
dspace.= cfg
</html>