small edit to article

doc/Article1.md

@@ -17,7 +17,7 @@ You may want to define fields ahead of time to help catch typos. For example, yo
 
 ### Pipelining
 
-To increase concurrency on a server connection and thus speed up threads sharing it, I pipeline requests over a connection, a' la [HTTP pipelining](http://en.wikipedia.org/wiki/HTTP_pipelining). Pipelining means sending multiple requests over the socket and receiving the responses later in the same order. This is faster than sending one request, waiting for the response, then sending the next request, and so on. The pipelining implementation uses [futures/promises](http://en.wikipedia.org/wiki/Futures_and_promises), which are simply implemented as IO actions. You are not exposed to the pipelining, because it is internal to *Cursor*, which iterates over the results of a query. More specifically, a query returns its cursor right away, locking the socket only briefly to write the request (allowing other threads to issue their queries). When a cursor is asked for its first result, it waits for the query response from the server. Also, when a cursor returns the last result of the current batch, it asynchronously requests the next batch from the server. This asynchronicity is automatic because the request returns a promise right away that the cursor will wait on when asked for the next result.
+To increase concurrency on a server connection and thus speed up threads sharing it, I pipeline requests over a connection, a' la [HTTP pipelining](http://en.wikipedia.org/wiki/HTTP_pipelining). Pipelining means sending multiple requests over the socket and receiving the responses later in the same order. This is faster than sending one request, waiting for the response, then sending the next request, and so on. The pipelining implementation uses [futures/promises](http://en.wikipedia.org/wiki/Futures_and_promises), which are simply implemented as IO actions. You are not exposed to the pipelining, because it is internal to *Cursor*, which iterates over the results of a query. Internally, a query returns its cursor right away, locking the socket only briefly to write the request (allowing other threads to issue their queries). When a cursor is asked for its first result, it waits for the query response from the server. Also, when a cursor returns the last result of the current batch, it asynchronously requests the next batch from the server. This asynchronicity is automatic because the request returns a promise right away that the cursor will wait on when asked for the next result.
 
 ### DB Action