Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Aligning behavior with other AWS SDKs #1567
As Rusoto continues to mature and gain users, we should keep in mind how much this project differs from other AWS SDKs.
I'd like to set a high level goal of getting Rusoto closer to how other AWS SDKs behave. There are some differences we can't avoid due to Rust and
How do others feel?
I see this as a very practical goal that benefits folks already familiar with aws ecosystem potentially making the transition to rust. The more familiar we can make interacting with aws services feel, the less friction organizations will likely run into when experimenting with rust in an professional setting.
I see two items that challenge that adoption that make rusoto fall below standard expectations for aws SDKs. Both I've worked around both in other crates and projects with rusoto but both likely are leave a betaware first impression on organizations toedipping into rust that don't have the luxury of someone that happens to be familiar with both aws service details and rust at the same time.
Luckily the information for both of these is available into the metadata used to generate the current interfaces in rusoto.
I took an initial stab at autopagination a while back but got a but stuck on using the botocore descriptions to interrogate responses for pagination tokens in a few corner cases. That's solvable but I know think it would be wise to see what the std lib story for async streams will look like. The futures crate had a nice streams API but now that the std lib is evolving is async story, streams maybe unstable territory.
I'd like to look at retries next. Some work here may be more focused in ironing our weak spots in error deserialization. In most many cases, knowing what can be retired depends on knowing what error is returned.