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.
Should individual bitstreams have arbitrary ids at the asset store API level?
Should the platform mandate event/listener model or polling model?
(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)
What transactional support should the asset store offer? Are single bitstream / AIP modification xactions acceptable?
A different take on asset store design can be found in RichardsAssetStoreApi