* Changed the `Azure::Core::Http::HttpMethod` regular enum into an extensible enum class.
* Update CL to mention removal of HttpMethodToString.
* Delete the default http method ctor.
* progress
* missing
* fix comp errors
* remove comments
* Bad merge with my recent changes to master
* Format
Co-authored-by: Ahson Khan <ahson_ahmedk@yahoo.com>
Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com>
This would unblock #2010.
Closes#2032.
Closes#1880.
I know this comes out of the blue, but it seems to me the right change to do. This is a proposal, let me know what you think.
First, I started with the fact that we need to make `CancelWhen()` public.
Then, I realized that I don't like the `CancelWhen()` naming. `CancelAt()` is better?
But `CancelAt()` sounds like an order to do something, not as getter.
So, it should be named `Get...`. `GetCancelWhen()`? `GetCancelAt()`? Sounds strage.
`GetDeadline()` - not bad, bit it is not that clear, what the deadline is.
And I looked at the `WithDeadline()` method. And in comment, the first line is `@brief Create a context with expiration.`.
"Expiration" sounds better explanation for the essense of the "deadline".
So, I went with `GetExpiration()`. I think "Expiration" is also a better name, because should we want to add the method called "bool IsExpired()", it comes naturally using the existing terminology, sounds better than "`IsPastDeadline()`".
Next thing - if we have "`GetExpiration()`", it is strange to have a method called `Get()`. So, we have `WithExpiration()` and `WithValue()`. So, it sounds like the getter should be called `GetValue()`. I did that rename as well.
Then, I looked at "`With...`" method naming. It is a factory method. If for getters we have `Get`, then for factory methods we should have `Create`. So, I renamed `WithExpiration()` and `WithValue()` to `CreateWithExpiration()` and `CreateWithValue()`.
Then I looked at `Context::time_point` typedef. First, in general, if we can avoid public typedefs, it is better, because we don't need to document them and worry if we broke client code when we change them.
Second, it is strange that we use `Azure::DateTime` everywhere, but not in context.
So, I replaced it with `Azure::DateTime`. It is good because it allows us to drop to/from epoch conversions (#1880), and really all that extra dance we do to cast to representation and back to datetime is the ways to stay within legal type casting limits of compiler type declaration, while in reality there isn't much that is happening in the code: `DateTime` is essentially an `int64`, and with all these conversions to epoch time, then to representation and back, compiler does not generate real code, it still operates with that only `int64`.
Why we cast to `DateTime::rep` and back at all? Context stores it as `atomic`, and I am not questioning that. You can't get `std::atomic<DateTime>` today explicitly, so we "extract" representation (`int64`) and store it as `std::atomic<DateTime::rep>`, which is the same thing as `std::atomic_int64`.
-- Update: --
1. "Expiration" => "Deadline" (Jeffrey's request)
2. Added `Context::HasExpiration()` (response to Jinming) // plus, we do have `HasValue()` so why not have `HasDeadline()`.
3. `WithDeadline()`, `WithValue` => Two overloads of `CreateChildContext()` (my own initiative).
-- Update 2: --
`CreateChildContext()` => `WithDeadline()`, `WithValue`
-- Update 3: --
Removed `HasDeadline()`
* Update relative links to sections in the contributing guide doc to fix link verification
* Make some source code change modifications to trigger GenerateRelease CI steps
* Don't use relative paths in links, instead use the full path from master to be consistent with other places
* Moved the `Base64Encode()` and `Base64Decode()` functions to be static members of a `Convert` class within the `Azure::Core` namespace.
* Add the class name in the source file for posix.
Usability studies found that static methods are generally not as user-friendly as instance methods. Folks new to the SDK have harder time discovering the APIs, they reverse the flow of typing, and the calling code ends up a bit more verbose because you have to spell out the whole namespace and type name when there aren't any using directives.
There doesn't seem to be a strong benefit or feasibility reason to keep these method statics which are typically harder to use and discover.
cc @kyle-patterson
Part of https://github.com/Azure/azure-sdk-for-cpp/issues/1789
From Jeff:
> BodyStream is only exposed to users when uploading/downloading bytes. Except for Storage almost no services do this at all; they read the stream and deserialize into a structure and the customer gets the structure - not the stream. Azure::Core:IO is a fine namespace.
* Make sure DateTime.ToString() works without requiring additional parameters by choosing RFC 3339 as the default.
* Address naming feedback and add some tests.
* Fix test warning by using static cast.
* VS2017 is right, we should be including `<iterator>`, if we use `std::inserter`. It fails to compile on VS2017 without that include.
Why if fails on 2017 and not 2019? Some of the other stdlib headers we include must be including `<iterator>` indirectly in 2019. But we should not be relying on that. Standard says, you use `std::inserter` - include `<iterator>`, if it works without that, that's a coincidence which may break beween versions of stdlib/compilers.
* VS 2017 does not fail because we don't include `<type_taits>` here, but formally we should include it too, because we use
`std::remove_reference` and `std::remove_const`. It just happens that `log.hpp` includes it, but we should not be relying on that.
This was found during local vcpkg verification - I happen to have it configured targeting VS2017. It does not mean it will fail in vcpkg CI, or would affect many customers, but some for sure. Verification on vcpkg CI looks good - https://github.com/microsoft/vcpkg/pull/16578 (it is based on our master as of Sat 3/6 + this fix).
I verified locally that it builds successfully on `x64-windows`, `x64-windows-static`, and `arm-uwp`.
We should run verification once again, once we have all the renames/moves in master.
* For consistency within the SDK, move Azure::Core::Context to be the last
parameter for various Azure::Core APIs.
* Fix merge conflict due to log policy file change.
* Update new client options tests
* Moved `BodyStream` and its derived types from `Azure::Core::Http`
namespace to `Azure::IO`, and update headers.
* Fix up clang formatting.
* Add missing winhttp bodystream namespace change.
* Update merge conflict related changes.
* Update header paths in includes.
* Add CaseInsensitiveMap<T>
* Drop unneccessary namespace qualification
* Comment working: more accurate description
* GCC and Clang fix (typename specification) + doxy comments for template parameters
* Remove Allocator template parameter - we can add it later if we need it, currently no need to commit to having it there
* Drop <T> template parameter. We can add it later with default value of std::string without breaking change
* Unit test
Co-authored-by: Anton Kolesnyk <antkmsft@users.noreply.github.com>
