split up azure_storage

[cataggar]

Per https://azure.github.io/azure-sdk/general_design.html#namespaces, please split up storage into crates:

• [x] azure_data_tables #546
• [x] ~azure_messaging_queues~ azure_storage_queues #493
• [x] azure_storage_datalake #545
• [x] azure_storage_blobs #499
• ~azure_storage_files~

[cataggar]

Previous crate naming details are in #304.

Not important, but good to know that the crate names match product marketing URLs well:

• https://azure.microsoft.com/services/storage/data-lake-storage/
• https://azure.microsoft.com/services/storage/blobs/
• https://azure.microsoft.com/services/storage/tables/
• https://azure.microsoft.com/services/storage/files/
• https://azure.microsoft.com/services/storage/queues/

.NET SDK packages for reference:

• https://www.nuget.org/packages/Azure.Data.Tables/
• https://www.nuget.org/packages/Azure.Storage.Blobs/
• https://www.nuget.org/packages/Azure.Storage.Files.Shares/
• https://www.nuget.org/packages/Azure.Storage.Files.DataLake/
• https://www.nuget.org/packages/Azure.Storage.Queues/

[johnbatty]

I'm going to have a go at this, starting with azure_messaging_queues.

[johnbatty]

A couple of questions about naming/structure after looking at this:

• azure_messaging_queues naming: I understand the rationale that queues logically belong in the messaging namespace rather than the storage namespace. However, all the other Azure SDKs I have looked at have it in the storage namespace. Are we happy that the Rust naming will not be consistent with the other SDKs?
• There is some common storage function (e.g. StorageClient). I therefore presume that the azure_storage crate should remain to contain this common code, even when the other function is split out into separate crates. Do you agree?

[johnbatty]

I've done azure_messaging_queues, moving on to azure_storage_blobs...

[thovoll]

A couple of questions about naming/structure after looking at this:

• azure_messaging_queues naming: I understand the rationale that queues logically belong in the messaging namespace rather than the storage namespace. However, all the other Azure SDKs I have looked at have it in the storage namespace. Are we happy that the Rust naming will not be consistent with the other SDKs?
• There is some common storage function (e.g. StorageClient). I therefore presume that the azure_storage crate should remain to contain this common code, even when the other function is split out into separate crates. Do you agree?

@JeffreyRichter or @heaths might be able to shed some light on the first question.

On the second question, I propose we eliminate the StorageAccountClient and the StorageClient, just like in the Java and .Net SDKs. Keep in mind that I have not looked at the other SDKs.

[JeffreyRichter]

I spoke to the other language architects about this. It turns out that putting queues in Storage was a mistake; they all meant to put it in Messaging. Basically the 1st language did Storage and the other languages just followed this. We can keep Storage for consistency.

We tend to favor replication code over having a common dependency for a few reasons:

• If we change the dependency for 1 client, then this may affect other clients
• It tends to ship the org chart again. What if Queues leaves Storage and goes to another team? (there is a chance this will happen).
• What in common can diverge over time and a breaking change in it will break all client lib dependent on it; not just the 1 lib that requires the break.
• Common can sometimes get stuff that is actually not common so this bloats the package
• Customers can't understand why something is the common package as opposed to the client lib-specific package - this hurts dicoverability and usability

[thovoll]

Thanks @JeffreyRichter. To be clear, you are saying that we should keep queues under storage correct?

I totally agree with not over-using common dependencies. More often than not, code duplication is trivial and way cheaper to maintain than a common dependency (as long as we are not duplicating any sophisticated algorithms).

[JeffreyRichter]

It's a hard call sometimes whether to maintain consistency across languages when you learn from a mistake and know something could be better. For true bugs and patterns that cause customer pain, we know we'd fix it in another language if we can and break language consistency.

In this case, it's just naming (not a real bug) and so let's keep queues under Storage instead of Messaging.

[johnbatty]

Thanks @JeffreyRichter - I'll update my PR for the queues crate to call it azure_storage_queues.

[johnbatty]

I'm moving on to azure_storage_datalake next...

Just to confirm - is it definitely azure_storage_datalake, rather than azure_storage_data_lake?

[johnbatty]

Next up... azure_data_tables...

[cataggar]

Just to confirm - is it definitely azure_storage_datalake, rather than azure_storage_data_lake?

Confirmed. Thanks @johnbatty