Skip to content

Conversation

rerkcp
Copy link
Contributor

@rerkcp rerkcp commented Mar 23, 2022

This PR implements the Azure Device Update API. The code is based on the security_keyvault crate.
Feedback welcome even if the PR is not merged.

@ghost
Copy link

ghost commented Mar 23, 2022

CLA assistant check
All CLA requirements met.

Comment on lines 23 to 26
let s_filter= match env::var("DEVICE_UPDATE_FILTER") {
Err(_e) => { "".to_owned() },
Ok(s) => { s }
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
let s_filter= match env::var("DEVICE_UPDATE_FILTER") {
Err(_e) => { "".to_owned() },
Ok(s) => { s }
};
let s_filter = env::var("DEVICE_UPDATE_FILTER").unwrap_or_default();

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done, thank you

@bmc-msft
Copy link
Contributor

Perhaps this would be a good candidate to wrap the service-generated code in a rust-idiomatic layer.

For reference: generated crate and docs

@rerkcp
Copy link
Contributor Author

rerkcp commented Apr 4, 2022

Perhaps this would be a good candidate to wrap the service-generated code in a rust-idiomatic layer.

For reference: generated crate and docs

I tried to do that in the beginning so as not to copy all the struct and enum definitions, but I ran into problems with integrating the svc crate and the sdk crate together due to Rusts checks on how crates can reference each other and could not get it to even compile. Is there an example on how to do this I could look at?

@rerkcp rerkcp requested a review from bmc-msft April 6, 2022 08:04
Copy link
Contributor

@rylev rylev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for contributing! I think this is a good start though we'll want to start moving towards things like using the pipeline architecture like we do in azure_data_cosmos. I'll merge this for now, and we can make improvements in follow-up PRs.

serde = { version = "1.0", features = ["derive"] }
getset = "0.1"
azure_core = { path = "../core", version = "0.2" }
tokio = { version = "1.0", features = ["full"] }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't need to depend on tokio.

@@ -0,0 +1,36 @@
use azure_device_update::DeviceUpdateClient;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a lot of these examples should be tests instead and combined together.

/// let client = DeviceUpdateClient::new("contoso.api.adu.microsoft.com", &creds).unwrap();
/// ```
#[derive(Debug)]
pub struct DeviceUpdateClient<'a, T> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're generally avoiding tying clients to some specific lifetime. We should just make it easily cloneable.

Comment on lines +86 to +94
let resp = reqwest::Client::new()
.put(&uri)
.bearer_auth(self.token.as_ref().unwrap().token.secret())
.header("Content-Type", "application/json")
.body(body)
.send()
.await
.unwrap();
let body = resp.text().await?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll want to use the pipeline architecture we're using in azure_data_ cosmos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants