Updated README.md.

Author: adityamukho

README.md

@@ -7,10 +7,11 @@ One might ask why, in the presence of so many available collectors ([Zipkin](htt
 Listed below are some reasons why *foxx-tracer-collector* was created:
 1. Traces (a trace is a collection of interrelated spans) generated inside a [Foxx Microservice](https://www.arangodb.com/docs/stable/foxx.html) have to be shipped out to an external system where they can be stored and analyzed. Unfortunately, the Foxx runtime is extremely restrictive about how its mounted services can communicate with the outside world.
 1. The only allowed networking option is to use Foxx's built-in [request](https://www.arangodb.com/docs/stable/foxx-guides-making-requests.html) module, but that too is entirely synchronous - meaning we cannot insert trace-posting requests in the main execution path without severely degrading latency and throughput metrics.
-1. A workaround to achieving asynchronicity is to use the [Task API](https://www.arangodb.com/docs/3.6/appendix-java-script-modules-tasks.html), but that would mean burdening the service with continually generating asynchronous tasks just to push out trace data, which is not its primary function.
-1. There are other, more nuanced limitations imposed by the 100% synchronous runtime that distributes a service deployment across multiple, isolated V8 contexts (in singular instances as well as in clusters) as well as the way the Task API works, which make an in-memory trace-buffering mechanism (with periodic, task-based flush) unfeasible.
+1. All existing CommonJS OpenTracing client libraries are naturally asynchronous in order to avoid this penalty, but this also means they cannot run within a Foxx V8 context. Therefore, a 100% synchronous client library is also required. This requirement is fulfilled by [foxx-tracer](https://github.com/RecallGraph/foxx-tracer) - a companion client library for *foxx-tracer-collector*.
+1. One way to achieve asynchronous execution in Foxx is to use the [Task API](https://www.arangodb.com/docs/3.6/appendix-java-script-modules-tasks.html), but that would mean burdening the service with continually generating asynchronous tasks just to push out trace data, which is not its primary function.
+1. There are other, more nuanced limitations, imposed by the 100% synchronous runtime (that distributes a service deployment across multiple, isolated V8 contexts in singular instances as well as in clusters), which make an in-memory trace-buffering mechanism (with periodic, task-based flush) unfeasible.
 1. Due to the reasons stated above, every trace that is initiated by an incoming request has to be flushed immediately once the request has been served. Naturally, this must be done with as little lag as possible.
-1. This is where *foxx-tracer-collector* comes to the rescue. It runs beside your traced service in the same DB instance, and exports a function to record spans that can be **directly invoked** (in-process) and returns instantly, with no blocking I/O performed.
+1. This is where *foxx-tracer-collector* comes to the rescue. It runs beside your traced service in the same DB instance, and works in tandem with the *foxx-tracer* client (installed in your service) to record spans by means of an exported function that is **directly invoked** (in-process) and returns instantly, with no blocking I/O performed.
 
 ## How it works
 Once a trace has been offloaded to the collector, your service is free to go back to its primary business, which is to serve user requests.