Azure Storage SDKs allow you to connect via connection strings. They are basically stringified versions of a subset the reqsign_azure_storage::Config struct's fields.
This relates to apache/opendal#6211 but I think it makes sense to also add it to reqsign as it's more or less analogous to the already existing Config::from_env(): https://github.com/Xuanwo/reqsign/blob/e88f8878b22ef6eb61edc33fc87d46e1866eeae2/services/azure-storage/src/config.rs#L89
Implementation Note
The endpoint of the Config is dependent on the Storage service used. With Azure Blob Storage for example, a connection string could contain either BlobEndpoint=https://myaccount.blob.core.windows.net or DefaultEndpointsProtocol =https;AccountName=myaccount;EndpointSuffix=core.windows.net.
The current implementation of Config::from_env seems to assume that a user wants to connect to Blob Storage endpoints. A first version of connection string parsing can make the same assumption. This would translate to looking at BlobEndpoint or formatting an endpoint from it's parts in a format like "{DefaultEndpointsProtocol}://{AccountName}.blob.{EndpointSuffix}" (note the literal blob).
There are other Azure Storage services that require a feature-complete parsing function to look at different values (QueueEndpoint, FileEndpoint or TableEndpoint) or use different storage service names when building up the endpoint from its parts (e.g. dfs for ADLSv2).
Since the current version of Config really is a BlobConfig, I believe this warrants its own issue (I will create one soon).
Azure Storage SDKs allow you to connect via connection strings. They are basically stringified versions of a subset the
reqsign_azure_storage::Configstruct's fields.This relates to apache/opendal#6211 but I think it makes sense to also add it to
reqsignas it's more or less analogous to the already existingConfig::from_env(): https://github.com/Xuanwo/reqsign/blob/e88f8878b22ef6eb61edc33fc87d46e1866eeae2/services/azure-storage/src/config.rs#L89Implementation Note
The endpoint of the Config is dependent on the Storage service used. With Azure Blob Storage for example, a connection string could contain either
BlobEndpoint=https://myaccount.blob.core.windows.netorDefaultEndpointsProtocol =https;AccountName=myaccount;EndpointSuffix=core.windows.net.The current implementation of
Config::from_envseems to assume that a user wants to connect to Blob Storage endpoints. A first version of connection string parsing can make the same assumption. This would translate to looking atBlobEndpointor formatting an endpoint from it's parts in a format like"{DefaultEndpointsProtocol}://{AccountName}.blob.{EndpointSuffix}"(note the literalblob).There are other Azure Storage services that require a feature-complete parsing function to look at different values (
QueueEndpoint,FileEndpointorTableEndpoint) or use different storage service names when building up the endpoint from its parts (e.g.dfsfor ADLSv2).Since the current version of
Configreally is aBlobConfig, I believe this warrants its own issue (I will create one soon).