Fix Storage naming to (mostly) match API Schema

[silvolu]

• Renaming noun "key" to "object" or close relative (Changing Key noun to be Blob in storage package. #560).
• Remove boto aliases (Remove boto aliases #568)
• Address other concerning naming conventions

(Above added by @dhermes on 1/19/2014)

---

The naming conventions appear to be modeled around s3's boto library, but the library is not compatible with S3. It seems like it might be more useful to use the JSON API resource names.
The major difference here is the use of "key" to represent an "object" resource. The Cloud Storage API JSON docs typically use the word "key" to refer to an API key or a service account private key file, never to a cloud object resource. Of course "object" is a reserved name in Python, but there are other possibilities.
With the hierarchy of connection/bucket/key, this looks a lot like boto without actually supporting s3, which could confuse users.

/cc @thobrla

[dhermes]

I agree. I was originally thrown off by the use of Key instead of Object, but quickly forgot about it.

@jgeewax You seem to have had some goal of being like boto. Can you articulate further?

I'd prefer we much the nouns / verbs of the actual API so developer's questions use the same language the API docs will use.

[jgeewax]

When I wrote this stuff originally (about a year ago) I was thinking that it'd be really nice if people could change import boto to import gcloud -- but I don't think that that panned out as I'd hoped for a variety of reasons.

I'd have no issue with aliasing at this point -- keeping Key for backwards compatibility and renaming to Object to better fit the API documentation on cloud.google.com.

[dhermes]

@jgeewax Backwards compatibility with what? Since we aren't at 1.0, we shouldn't worry about backwards compat.

[jgeewax]

Technically you're right, but aliases are incredibly low on the maintenance scale and only one extra line... Any huge objection to not punishing those people who were early adopters and want to upgrade their version w/o changing tons of code?

[thobrla]

While aliases are low maintenance, I suspect the interface will need to change address other issues, so I don't think establishing a back-compat precedent now is a good idea. It might be easier just to write a simple conversion tool since this is (for now) a string substitution.

[silvolu]

If we think that the API is bad, we should get rid of it; even though the alias are low maintenance, we would use them to keep 'cruft' around.

[jgeewax]

If we're all in agreement, then sure - let's rename :)

[dhermes]

On it.

[dhermes]

Closing this out (I think the Key -> Blob rename mostly covered this). Still doing a comprehensive quality / usability pass over storage.

[jgeewax]

Do we have any other naming convention concerns? I assume not, and am going to tick @silvolu 's last checkbox.

[dhermes]

Thanks