Spandan, I am still waiting for your response to the third paragraph below.
On Tue, Mar 21, 2017 at 07:52:29PM -0400, Andrew Gaul wrote: > [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/ -- Andrew Gaul http://gaul.org/
