I agree that we should make the filesystem and transient blobstores similar to the real blobstores. However, I'm not sure if keeping the LocalAsyncBlobStore around helps that. Has it been useful for test and dev of the long running operations that you mention? Is it useful today for these operations, now that the decision to get rid of the AsyncBlobStore is made?
I wanted to introduce a new method on the BlobStore object called removeBlobs(Collection<String> blobNames). This would internally identify whether the api/provider is a capable of doing bulk delete and make the calls accordingly. Without this change, I need to add the removeBlobs method to the AsyncBlobStore and whoever depends on it. This is unnecessary code which is going to get deleted any way. I'm planning to send out an email on the jclouds-dev list with some more details and request suggestions before I actually send out the pull request. But this LocalAsyncBlobstore was getting in my way. This is what prompted me to make this change in the first place. Thoughts? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/220#issuecomment-45668395
