On one hand I'm quit surprised this didn't already exist, but on the other hand I can't see a huge market for it?

I love C++, so I'm excited.

I can imagine non-C++ libraries (e.g. Python or Ruby) wrapping the C++ interface rather than using a custom implementation.

May I ask why? Plenty of implementations already exist for other languages, and since the interface is just HTTP, I see little benefit to wrapping the C++ library.

Official, full support, instead of a custom implementation where it can take weeks to add support for a new service that's already a part of the C++ lib. Also, there are some newer languages out there that don't have quality libraries for AWS, but do have C extension support. This will allow wrappers for to be created so these languages can be used with AWS as well. Just take a look at how the Java lib is used.

I'm still not sure I follow. There are plenty of first-party fully supported SDK's for various languages, eg. Ruby, Node.js, Java, .NET, etc: https://aws.amazon.com/tools/

In fact from personal experience of the Node one the SDK uses the API descriptor to generate the client (Which makes unit testing it tricky incidentally, but I digress).

In my experience, it's just easier to take their API descriptor file (JSON IIRC) and generate a client from it.

This is what boto3 does

Wouldn't that be WADL?

No, WADL is XML. You can see some of the data files in the boto3 repository: https://github.com/boto/boto3/tree/develop/boto3/data

It is somewhat similar in concept

WADL is an description language for REST services.

Given that it is just an HTTP API, I'm not sure it would actually be that much faster to wrap a C++ API than just write a native lib. Plus unless the wrapper is written by Amazon as well, it's not really "official, full support."

I cant. C++ is a pain to wrap.

Most good libraries written in C++ that are meant to be used as libraries in other languages expose a C interface. I don't see a C interface in their docs.

Games, I would guess would be the market. Though yes it is strange it took so long.

Could upload large binary blobs of game state to S3 instead of building your own backend. Though that means having no backend to validate data :-/

Post it through the API gateway into a lambda function, validate it, and then store it.

Finally, and I love the simplicity of the API. Can't wait to play with it; though I'd have loved to see modern C++ futures to have been used, given that it was just released. But even then, finally there is at least something!

At least in the following file, all *Callable functions return a future:

https://github.com/awslabs/aws-sdk-cpp/blob/master/aws-cpp-s...

I can see so much potential for this. For example, if you don't want to solely distribute on Steam but want an auto-update feature then it'll be a lot easier with AWS.

Not C++ specific, but I'm hopeful that we'll see some game distribution platforms built on top of this kind of tech. More competitors to Steam will be a good thing.

I bet Steve Yegge loves this (https://sites.google.com/site/steveyegge2/tour-de-babel).

>This SDK has been specifically designed with game developers in mind

Can anyone explain to me how game developers would use this with AWS? (just for hosting assets?)

As a mobile game developer we use a lot of different aws functionality. We don't use c++ a lot though. Console games do so this will probably be used by those although most aws access is done through a server not directly from the client

high-score tables, state for online turn-based games, hosting user-generated maps, auto-update system, etc

Multiplayer...

Is this auto-generated ?

Most likely, given this quote at the end:

> We also are adding support for individual services as we become more confident that the client generator can properly support each protocol.

Yes. I'm pretty sure most if not all of the official AWS SDKs are, with only a bit of hand-coded parts tossed in