Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project Organization Open Questions #6

Closed
4 tasks
rylev opened this issue Oct 9, 2020 · 3 comments
Closed
4 tasks

Project Organization Open Questions #6

rylev opened this issue Oct 9, 2020 · 3 comments

Comments

@rylev
Copy link
Contributor

rylev commented Oct 9, 2020

  • The storage crate is not ideally structured. I simply moved the previous crates into a single crate with submodules. We might want to rearrange things.
  • The storage crate defaults to all features. This is convenient, but means that by default the project will be slow to build. What's the right trade off here?
  • Should we rename auth_aad to just auth and have AAD functionality behind a feature (so that if we add new auth varieties we can simply add new features?
  • I've left azure_sdk_core named that way even though it contains sdk. I think azure_core is a bit too generic of a package name.
@heaths
Copy link
Member

heaths commented Oct 9, 2020

Please compare with other language repos for examples. We strive for naming consistency (while remaining idiomatic) to make it easier to use different libraries for different languages in multi-lingual projects. For example, for auth we actually have azure-identity, though we are currently talking about moving bearer token (including challenges) into azure-core.

For storage, I'd recommend the same. As much as possible, think about how our existing storage libraries are modularized. Features in Rust seems ideal, but perhaps those features can better align with packages in, say, JavaScript or Python.

Going with the naming consistency, azure-core would be preferable. It's what all the other languages do. That this is an SDK is already implied.

As for auth in general, azure-identity has many different authentication classes that can be used together with DefaultAzureCredential. I've linked the C# one because that probably has the most different operations it will try. It's optimized to work with both production and development environments by checking first for production environment variables or MSI, then falls back to developer methods like azure CLI or VS auth records. We'll want to do the same, as this is what most people use - and why we designed it as we did.

@rylev
Copy link
Contributor Author

rylev commented Oct 12, 2020

I moved the question about the auth crate naming to issue #32

@rylev
Copy link
Contributor Author

rylev commented Jan 27, 2021

Closing this as we've answered most of these questions.

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

No branches or pull requests

2 participants