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