Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

This page aims to enumerate and briefly describe issues with the DSpace 2 Asset Store API design.

This content should probably go on AssetStoreApi, but that page contains Rob's p.o.v. and I (jim) don't want to monkey with it.

Identifiers

Should individual bitstreams have arbitrary ids at the asset store API level?

Keeping DSpace modules' indices/caches synchronised with asset store contents

Should the platform mandate event/listener model or polling model?

Distributed DSpace

(A.K.A. replication, mirroring, federation, sharing, etc...)

What level to do replication / mirroring / federation? Should the DSpace platform dictate that this can't happen at the asset store level? (If so, how to employ storage grid-style technologies? – RobertTansley)

Transactions

What transactional support should the asset store offer? Are single bitstream / AIP modification xactions acceptable?

Alternate APIs

A different take on asset store design can be found in RichardsAssetStoreApi

  • No labels