Doc updates for v3.1.0

Author: wravery

README.md

@@ -108,9 +108,9 @@ Command line options:
   --separate-files       Generate separate files for each of the types
 ```
 
-I've only tested this with Boost 1.69.0, but I expect it will work fine with most other versions. The Boost dependencies
-are only used by the `schemagen` utility at or before your build, so you probably don't need to redistribute it or the
-Boost libraries with your project.
+I've tested this with several versions of Boost going back to 1.65.0. I expect it will work fine with most versions of
+Boost after that. The Boost dependencies are only used by the `schemagen` utility at or before your build, so you
+probably don't need to redistribute it or the Boost libraries with your project.
 
 If you are building shared libraries on Windows (DLLs) using vcpkg or `BUILD_SHARED_LIBS=ON` in CMake, be aware that this
 adds a runtime dependency on a Boost DLL. The `schemagen` tool won't run without it. However, in addition to automating
@@ -148,10 +148,10 @@ All of the generated files are in the [samples](samples/) directory. There are t
 the generated code, one which creates a single pair of files (`samples/unified/`), and one which uses the
 `--separate-files` flag with `schemagen` to generate individual header and source files (`samples/separate/`)
 for each of the object types which need to be implemeneted. The only difference between
-[UnifiedToday.h](samples/today/UnifiedToday.h)
-and [SeparateToday.h](samples/today/SeparateToday.h) should be that the `SeparateToday` use a generated
-[TodayObjects.h](samples/separate/TodayObjects.h) convenience header which includes all of the inidividual
-object header along with the rest of the schema in [TodaySchema.h](samples/separate/TodaySchema.h).
+[TodayMock.h](samples/today/TodayMock.h) with and without `IMPL_SEPARATE_TODAY` defined should be that the
+`--separate-files` option generates a [TodayObjects.h](samples/separate/TodayObjects.h) convenience header
+which includes all of the inidividual object header along with the rest of the schema in
+[TodaySchema.h](samples/separate/TodaySchema.h).
 
 # Build and Test
 

doc/parsing.md

@@ -46,10 +46,11 @@ The document must use a UTF-8 encoding. If you need to handle documents in
 another encoding you will need to convert them to UTF-8 before parsing.
 
 If you need to convert the encoding at runtime, I would recommend using
-`std::wstring_convert`, with the cavevat that it has been
+`std::wstring_convert`, with the caveat that it has been
 [deprecated](https://en.cppreference.com/w/cpp/locale/wstring_convert) in
 C++17. You could keep using it until it is replaced in the standard, you
 could use a portable non-standard library like
 [ICU](http://site.icu-project.org/design/cpp), or you could use
 platform-specific conversion routines like
-[WideCharToMultiByte](https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte) on Windows.
+[WideCharToMultiByte](https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte)
+on Windows instead.

doc/resolvers.md

@@ -34,15 +34,15 @@ schema {
 
 Executing a query or mutation starts by calling `Request::resolve` from [GraphQLService.h](../include/graphqlservice/GraphQLService.h):
 ```cpp
-std::future<response::Value> resolve(const std::shared_ptr<RequestState>& state, const peg::ast_node& root, const std::string& operationName, response::Value&& variables) const;
+std::future<response::Value> resolve(const std::shared_ptr<RequestState>& state, peg::ast& query, const std::string& operationName, response::Value&& variables) const;
 ```
 By default, the `std::future` results are resolved on-demand but synchronously,
 using `std::launch::deferred` with the `std::async` function. You can also use
 an override of `Request::resolve` which lets you substitute the
 `std::launch::async` option to begin executing the query on multiple threads
 in parallel:
 ```cpp
-std::future<response::Value> resolve(std::launch launch, const std::shared_ptr<RequestState>& state, const peg::ast_node& root, const std::string& operationName, response::Value&& variables) const;
+std::future<response::Value> resolve(std::launch launch, const std::shared_ptr<RequestState>& state, peg::ast& query, const std::string& operationName, response::Value&& variables) const;
 ```
 
 ### `graphql::service::Request` and `graphql::<schema>::Operations`

doc/subscriptions.md

@@ -64,6 +64,17 @@ for every required field in the subscription `query`.
 void deliver(const SubscriptionName& name, const SubscriptionFilterCallback& apply, const std::shared_ptr<Object>& subscriptionObject) const;
 ```
 
+By default, `deliver` invokes all of the `SubscriptionCallback` listeners with `std::future`
+payloads which are resolved on-demand but synchronously, using `std::launch::deferred` with the
+`std::async` function. There's also a version of each overload which  lets you substitute the
+`std::launch::async` option to begin executing the queries and invoke the callbacks on multiple
+threads in parallel:
+```cpp
+void deliver(std::launch launch, const SubscriptionName& name, const std::shared_ptr<Object>& subscriptionObject) const;
+void deliver(std::launch launch, const SubscriptionName& name, const SubscriptionArguments& arguments, const std::shared_ptr<Object>& subscriptionObject) const;
+void deliver(std::launch launch, const SubscriptionName& name, const SubscriptionFilterCallback& apply, const std::shared_ptr<Object>& subscriptionObject) const;
+```
+
 ## Handling Multiple Operation Types
 
 Some service implementations (e.g. Apollo over HTTP) use a single pipe to