3 ms·
Yes, there's a lot of types we generate from the botocore service definitions. Any suggestions on reducing the noise in our docs to make usage clearer? I'd lo
by matthewkmayer 10y ago
Yes, there's a lot of types we generate from the botocore service definitions. Any suggestions on reducing the noise in our docs to make usage clearer? I'd love an issue on Github with thoughts. https://github.com/rusoto/rusoto https://github.com/rusoto/rusoto
We also have a crate that's designed to provide higher level abstractions. Rusoto is analogous to botocore and rusoto_helpers (https://github.com/rusoto/rusoto/tree/master/helpers https://github.com/rusoto/rusoto/tree/master/helpers) will be closer to boto3. It's on the back burner as we focus on completing the core functionality.
Async support is still an open question. If requested we can make that happen before 1.0. Feel free to weigh in: https://github.com/rusoto/rusoto/issues/318 https://github.com/rusoto/rusoto/issues/318 .
- nicoburns 10y agoDocs wise, a big help would be to highlight 'important' structs. When I was first reading the docs, I saw a great big list of structs including ones like SpecificMethodInputAeguments, and completely missed the KinesisClient structure that all the actual methods are implemented on!
- matthewkmayer 10y agoI've made https://github.com/rusoto/rusoto/issues/519 https://github.com/rusoto/rusoto/issues/519 for this particular issue, along with a sample way of calling out the important Client struct for each service. Thanks for the idea!