You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Gaul <ga...@apache.org> on 2017/04/21 21:17:54 UTC

Re: Planning Changes for Only Azure

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/