Usage of magic values to specify known metadata instead of static types

[jeremyong]

Specifying magic strings like "HashKey" to populate data strike me as an odd choice. Why not expose compile-time types to encode this (and other special types) rather than requiring they be hashed to a map all the time? In addition, it looks like the implementation uses a vanilla map as opposed to an unordered map.

[JonathanHenson]

Most of the hard coded strings in individual service clients are from code that is generated from the models. Do you have a specific file in mind that we could have a more fruitful conversation about?

As to using a hash map instead of an RB Tree, that is a whole other long optimization argument that probably wouldn't be productive on this forum. We did think about it and decided against it. We will certainly reevaluate this decision as the api grows and changes.

[JonathanHenson]

Closing pending more info.

[JonathanHenson]

Now that I think about it this may be a more actionable issue. Is your concern that the metadata for S3 is a string string map instead of keyed by some constants?

If so, the reason that is what it is, is that s3 has not defined an enumeration of acceptable metadata types for the generator to pick up and use. If that is the case, then I can see if we can update the service definitions for you. I'll make some inquiries.

[jeremyong]

Yea that's right, and this is true for other services like DynamoDB as well.

[JonathanHenson]

One thing to remember, is that these definitions come straight off of the api definition. The clients are "dumb" low-level clients. I think these concerns would be more workable in some higher-level apis. For example, we could add easily add some metadata constants to the transfer client.