[Sorry for my delayed responses previously and for the next week; I am traveling.]
We generally follow a "rule of three" for new additions to the portable abstractions like BlobStore, where three implementations need to support some functionality before we percolate it to the abstraction. Since this functionality does not really require provider support, what benefit does skipping the other implementations give? I am happy to review incomplete work to make sure we have consensus on the approach but merging should have all functionality. I also wonder if a simpler implementation of async might suit your needs? What if provider added a putBlob implementation which returned an OutputStream[1] which S3Proxy could push through Jetty to write asynchronously? This would address a popular user request. [1] https://issues.apache.org/jira/browse/JCLOUDS-769 On Thu, Mar 16, 2017 at 05:17:07AM -0000, Spandan Thakur wrote: > Hi Andrew, > > Thanks for all the feedback :) > > I had one final question. So for the real implementation we are planning to > start with important methods on the AzureBlobStore (put, get, delete,etc) and > then move to other methods in AzureBlobStore. Do note that our focus is only > on Azure (as of now) and we are planning to throw unsupported error for other > stores. > > Is this ok as far as contribution goes? Can we first have a azure related > async implementation and throwing unsupported exceptions for other stores? > > Regards, > Spandan > > -- Andrew Gaul http://gaul.org/
