Provide async methods

In order to stay DRY, make the current methods async, then rewrite the sync methods by calling the async methods and Wait().

[Genbox]

This has been implemented in 04c3f78710010372bb309dd4e6433515d85f55a3

[Genbox]

You have to understand that I’m looking at it from a library point of view. Introducing new language features like async that depends on Task limits the portability of the library and force the library to be build with a newer version of .NET due to the TPL dependency. Hopefully this will change soon as .NET Core comes out and we can bundle the TPL dependency directly in the library.

There is also the issue with new users. Think back to when you first started C# development and you saw 100 methods/properties/fields in intellisense, and half of them you did not even understand how to call (async callbacks). I’ve always tried to keep it as simple as possible API wise and do all the complex stuff under the hood. In this case, the library is just a simple wrapper for the HTTP API with some methods for convenience.

95% of all projects don’t care if you spawn another thread to do async work as the memory overhead is small(ish), and since this API is only targeting the VT public API where you have a limit of 4 request/sec, it really does not matter much at all, and the compromise between usability, simplicity vs. memory overhead is for me a no-brainer, so I go with usability and simplicity over async features.

That being said, I’m doing a large project with performance in mind, and I have to build it with the private VT API, so I’m kinda forced to rethink a lot of things. You mentioned rate limits in #16 as well as async in this issue. There have also been requests over the years for file extension filters, rotating API keys and much more, and usually the answer have been the same: YOU have to decide on how to do that stuff, this is not an enterprise API with “all you can do” features 😃

However, as I’m going to rework a lot of things in the private VT API, async is not a bad idea, as well as simple work queuing (due to potential large amounts of work, and limited batch sizes can be sent to VT private API). So I’m reopening this issue as a reminder.