-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Api2.1 #46
Conversation
wip auth Azure wip Azure credentials stash
I have just read through the migration document. I had a query on some of the design decisions for the new API, particularly around how the bucket name is used. It looks as though I can specify the bucket name in the storage URL still (which is great, that's how we want to use it as it keeps our config very simple as just a single url), but then the strange bit, it looks like I also have to re-specifcy it in every call on the storage adapter? This seems a bit weird and unfriendly as I already specified it. Maybe I've misunderstood the change? I'd expect that if I've specified the bucket in the URL of the storage setup then that's the ONLY bucket I can access through that particular storage instance (credentials are likely tied to that bucket anyway). At the very least it should be used as the default if I omit the bucket name in later storage API calls. If I don't specify the bucket in the storage constructor then it makes sense to require it on every later API call. Secondly the changes in the URL format, was there a reason behind diverging away from the more known s3://buckname/path/to/object type URIs that the AWS cli supports? |
Both GCP and AWS seems to use a similar URI format for bucket identification: GCP: gs://bucketname/path/to/object AWS: s3://buckname/path/to/object I understand extra params are required such as region, credentials etc... but the v1 formats handled that nicely. |
I have drafted a new API and I am open to suggestions from the community.
You can find the draft in the change.log
Thanks!