Create azure_storage_queues crate from azure_storage::queue

[johnbatty]

As per: #483

This is work in progress. I've created the new crate, and the main code builds but there is some cleanup to do, the tests will need updating, and examples need moving/updating.

I'm looking for feedback on whether this broadly the change that you are looking for, and have a few specific questions/issues:

StorageClient methods reference queue functions

I originally moved the entire queue module to the new crate, but that caused some build issues/circular dependencies due to methods on StorageClient that reference functions in the queue module, e.g. StorageClient::list_queues(...), StorageClient::get_queue_service_properties(...). To get the build working I moved these specific requests/responses back into the storage crate. I'm looking for suggestions on what the right approach is for these.

Possible options:

• Stick with my current implementation, i.e. have a small queue module remaining within storage for these StorageClient level functions
• Move these functions to the new crate, and implement the queue-related functions of StorageClient as a new trait implemented in the new crate. I guess a downside of that is that they won't be visible if users look at the documentation for StorageClient.

New crate requires access to azure_storage modules and functions that are not currently public

I got the build working by making these public, but am looking for feedback on whether this the right thing to do.

• storage::xml - A small utility module with a single function. Could possible just duplicate this within the new crate.
• StorageClient methods: storage_account_client(...), queue_url_with_segments(...), prepare_request(...)

[johnbatty]

I've done some more work on this, and I think it is now looking in better shape.

Regarding the StorageClient methods reference queue functions issue, I took a look at how the other Azure SDKs handle these service-level functions. Turns out they have a QueueServiceClient for these:

• Python: https://azuresdkdocs.blob.core.windows.net/$web/python/azure-storage-queue/12.1.0/index.html#clients
• .NET: https://azuresdkdocs.blob.core.windows.net/$web/dotnet/Azure.Storage.Queues/12.8.0/api/Azure.Storage.Queues/Azure.Storage.Queues.QueueServiceClient.html

I therefore decided to use this approach, and have created a new QueueServiceClient struct in the new azure_messaging_queues crate. This simply wraps azure_storage::StorageClient, but means that the service level functions can now all be moved into the azure_messaging_queues crate where they belong.

I implement a trait to allow a QueueServiceClient to be created from a StorageAccount, so you can write this:

    let storage_account =
        StorageAccountClient::new_access_key(http_client.clone(), &account, &master_key);
    let queue_service = storage_account.as_queue_service_client();

    let response = queue_service.get_queue_service_stats().execute().await?;

While I was working on the examples, I noticed that all of them had this slightly verbose code to obtain a queue client:

    let queue = StorageAccountClient::new_access_key(http_client.clone(), &account, &master_key)
        .as_storage_client()
        .as_queue_client(queue_name);

To help ergonomics I implemented AsQueueClient for StorageAccountClient, so you can now get a QueueClient directly from a StorageAccountClient:

    let queue = StorageAccountClient::new_access_key(http_client.clone(), &account, &master_key)
        .as_queue_client(queue_name);

All the tests and examples are now fixed up and working, and the azure_storage::queues module is gone!

[thovoll]

Thank you for taking this on @johnbatty! I've recently been around this neck of the woods, so just for your awareness and potential follow-up PRs:

• Remove traits AsDataLakeClient and AsFileSystemClient #491
• Allow creation of nested clients directly? #490
• [Tracking Issue] Create/Convert ADLS Gen2 (data_lake) using Pipeline Architecture #496

[johnbatty]

@thovoll Thanks for the heads-up on the other related issues/PRs.

[johnbatty]

Renamed to azure_storage_queues following discussion in #483.

[thovoll]

@johnbatty should these have been added to the new crate?

[johnbatty]

@thovoll I don't think so. I believe that examples only need to be included in Cargo.toml if they need additional flags - in this case to add required-features=["queue"]. In the new crate, this feature flag no longer exists, so we can remove the example sections from Cargo.toml.

Let me know if you disagree, or I am missing something.

[thovoll]

I vaguely remember Cargo complaining when I added examples that were not in Cargo.toml, but it might indeed be because of required-features. If you can run the examples using Cargo, we're all set I think :)