Grammatical/Typo changes
Patch: Pooja Chandak
This closes #2271
diff --git a/doc/specs/HeaderFormat.md b/doc/specs/HeaderFormat.md
index 0456f1e..9b74159 100644
--- a/doc/specs/HeaderFormat.md
+++ b/doc/specs/HeaderFormat.md
@@ -46,7 +46,7 @@
don't know how to transform the data.
Conversely, data in the info headers is ignorable. This should only
-be things like timestamps, debuging tracing, etc. Using the header
+be things like timestamps, debugging tracing, etc. Using the header
size you should be able to skip this data and read the payload safely
if you don't know the info ID.
@@ -61,7 +61,7 @@
Header will be padded out to next 4-byte boundary with `0x00`.
Max frame size is `0x3FFFFFFF`, which is slightly less than `HTTP_MAGIC`.
-This allows us to distingush between different (older) transports.
+This allows us to distinguish between different (older) transports.
### Transform IDs:
diff --git a/doc/specs/idl.md b/doc/specs/idl.md
index 7563310..39b2ddd 100644
--- a/doc/specs/idl.md
+++ b/doc/specs/idl.md
@@ -104,7 +104,7 @@
### Field Requiredness
-There are two explicit requiredness values, and a third one that is applied implicity if neither *required* nor *optional* are given: *default* requiredness.
+There are two explicit requiredness values, and a third one that is applied implicitly if neither *required* nor *optional* are given: *default* requiredness.
[18] FieldReq ::= 'required' | 'optional'
@@ -144,7 +144,7 @@
### XSD Options
-N.B.: These have some internal purpose at Facebook but serve no current purpose in Thrift. Use of these options is strongly discouraged.
+N.B.: These have some internal purpose at Facebook but serve no current purpose in Thrift. The use of these options is strongly discouraged.
[19] XsdFieldOptions ::= 'xsd_optional'? 'xsd_nillable'? XsdAttrs?
@@ -236,7 +236,7 @@
Why does position of `CppType` vary between `SetType` and `ListType`?
* std::set does sort the elements automatically, that's the design. see [Thrift Types](/docs/types) or the [C++ std:set reference][] for further details
- * The question is, how other languages are doing that? What about custom objects, do they have a Compare function the set the order correctly?
+ * The question is, how other languages are doing that? What about custom objects, do they have a Compare function to set the order correctly?
[C++ std:set reference]: http://www.cplusplus.com/reference/stl/set/
diff --git a/doc/specs/thrift-binary-protocol.md b/doc/specs/thrift-binary-protocol.md
index a852685..fc3338f 100644
--- a/doc/specs/thrift-binary-protocol.md
+++ b/doc/specs/thrift-binary-protocol.md
@@ -24,10 +24,10 @@
--------------------------------------------------------------------
-->
-This documents describes the wire encoding for RPC using the older Thrift *binary protocol*.
+This document describes the wire encoding for RPC using the older Thrift *binary protocol*.
The information here is _mostly_ based on the Java implementation in the Apache thrift library (version 0.9.1 and
-0.9.3). Other implementation however, should behave the same.
+0.9.3). Other implementation, however, should behave the same.
For background on Thrift see the [Thrift whitepaper (pdf)](https://thrift.apache.org/static/files/thrift-20070401.pdf).
@@ -150,7 +150,7 @@
Note that the field name is not encoded so field renames in the IDL do not affect forward and backward compatibility.
The default Java implementation (Apache Thrift 0.9.1) has undefined behavior when it tries to decode a field that has
-another field-type then what is expected. Theoretically this could be detected at the cost of some additional checking.
+another field-type than what is expected. Theoretically, this could be detected at the cost of some additional checking.
Other implementation may perform this check and then either ignore the field, or return a protocol exception.
A *Union* is encoded exactly the same as a struct with the additional restriction that at most 1 field may be encoded.
@@ -213,7 +213,7 @@
The element-type values are the same as field-types. The full list is included in the struct section above.
-The maximum list/set size is configurable. By default there is no limit (meaning the limit is the maximum int32 value:
+The maximum list/set size is configurable. By default, there is no limit (meaning the limit is the maximum int32 value:
2147483647).
## Map
diff --git a/doc/specs/thrift-protocol-spec.md b/doc/specs/thrift-protocol-spec.md
index 0c1a61c..080487e 100644
--- a/doc/specs/thrift-protocol-spec.md
+++ b/doc/specs/thrift-protocol-spec.md
@@ -33,7 +33,7 @@
structure. There are some "dumb" terminals like STRING and INT
that take the place of an actual encoding specification.
-They key point to notice is that ALL messages are just one wrapped
+The key point to notice is that ALL messages are just one wrapped
`<struct>`. Depending upon the message type, the `<struct>` can be
interpreted as the argument list to a function, the return value
of a function, or an exception.
diff --git a/doc/specs/thrift-rpc.md b/doc/specs/thrift-rpc.md
index d45c06f..fbff3b6 100644
--- a/doc/specs/thrift-rpc.md
+++ b/doc/specs/thrift-rpc.md
@@ -24,15 +24,15 @@
--------------------------------------------------------------------
-->
-This document describes the high level message exchange between the Thrift RPC client and server.
+This document describes the high-level message exchange between the Thrift RPC client and server.
See [thrift-binary-protocol.md] and [thrift-compact-protocol.md] for a description of how the exchanges are encoded on
the wire.
-In addition, this document compares the binary protocol with the compact protocol. Finally it describes the framed vs.
+In addition, this document compares the binary protocol with the compact protocol. Finally, it describes the framed vs.
unframed transport.
The information here is _mostly_ based on the Java implementation in the Apache thrift library (version 0.9.1 and
-0.9.3). Other implementation however, should behave the same.
+0.9.3). Other implementation, however, should behave the same.
For background on Thrift see the [Thrift whitepaper (pdf)](https://thrift.apache.org/static/files/thrift-20070401.pdf).
@@ -93,14 +93,14 @@
not encode or decode a message or struct.
In the Java implementation (0.9.3) there is different behavior for the synchronous and asynchronous server. In the async
-server all exceptions are send as a `TApplicationException` (see 'Response struct' below). In the synchronous Java
+server all exceptions are sent as a `TApplicationException` (see 'Response struct' below). In the synchronous Java
implementation only (undeclared) exceptions that extend `TException` are send as a `TApplicationException`. Unchecked
exceptions lead to an immediate close of the connection.
Type `Oneway` is only used starting from Apache Thrift 0.9.3. Earlier versions do _not_ send TMessages of type `Oneway`,
even for service methods defined with the `oneway` modifier.
-When client sends a request with type `Oneway`, the server must _not_ send a response (steps 3 and 4 are skipped). Note
+When the client sends a request with type `Oneway`, the server must _not_ send a response (steps 3 and 4 are skipped). Note
that the Thrift IDL enforces a return type of `void` and does not allow exceptions for oneway services.
## Request struct
@@ -151,7 +151,7 @@
## Compatibility
A server could automatically determine whether a client talks the binary protocol or the compact protocol by
-investigating the first byte. If the value is `1000 0001` or `0000 0000` (assuming a name shorter then ±16 MB) it is the
+investigating the first byte. If the value is `1000 0001` or `0000 0000` (assuming a name shorter than ±16 MB) it is the
binary protocol. When the value is `1000 0010` it is talking the compact protocol.
## Framed vs. unframed transport