From 23dcbe84f8ed9f60ac38478eb12618c5a5b6bda4 Mon Sep 17 00:00:00 2001
From: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Date: Fri, 4 Oct 2019 23:06:12 -0400
Subject: [PATCH] Add list of exporters that are recommended for SDK (#284)

* Add list of exporters that are recommended for SDK

Based on previous discussion [1] this PR adds a recommendation to include
exporters for several open-source protocols in language libraries.

Addresses issue https://github.com/open-telemetry/opentelemetry-specification/issues/6

[1] - https://github.com/open-telemetry/opentelemetry-specification/pull/277#discussion_r330372034

* PR fixes
---
 specification/library-guidelines.md | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/specification/library-guidelines.md b/specification/library-guidelines.md
index 8110a32570f..46a512e02a3 100644
--- a/specification/library-guidelines.md
+++ b/specification/library-guidelines.md
@@ -16,9 +16,20 @@ _Note to Language Library Authors:_ OpenTelemetry specification, API and SDK imp
 
 3. The developers of the final application normally decide how to configure OpenTelemetry SDK and what extensions to use. They should be also free to choose to not use any OpenTelemetry implementation at all, even though the application and/or its libraries are already instrumented.  The rationale is that third-party libraries and frameworks which are instrumented with OpenTelemetry must still be fully usable in the applications which do not want to use OpenTelemetry (so this removes the need for framework developers to have "instrumented" and "non-instrumented" versions of their framework).
 
-4. Language library implementation must be clearly separated into wire protocol-independent parts that implement common logic (e.g. batching, tag enrichment by process information, etc.) and protocol-dependent telemetry exporters. Telemetry exporters must contain minimal functionality, thus enabling vendors to easily add support for their specific protocol.
+4. The SDK must be clearly separated into wire protocol-independent parts that implement common logic (e.g. batching, tag enrichment by process information, etc.) and protocol-dependent telemetry exporters. Telemetry exporters must contain minimal functionality, thus enabling vendors to easily add support for their specific protocol.
 
-5. Language library implementation should include an exporter for OpenTelemetry Protocol (when the protocol is specified and approved) and may include an exporter that writes to standard output (to use for debugging and testing). Vendor-specific exporters (exporters that implement vendor protocols) should not be included in language libraries and should be placed elsewhere (the exact approach for storing and maintaining vendor-specific exporters will be defined in the future).
+5. The SDK implementation should include the following exporters:
+    - Jaeger.
+    - Zipkin.
+    - OpenCensus.
+    - Prometheus.
+    - OpenTelemetry Protocol (when the protocol is specified and approved).
+    - Standard output (or logging) to use for debugging and testing as well as an input for the various log proxy tools.
+    - In-memory (mock) exporter that accumulates telemetry data in the local memory and allows to inspect it (useful for e.g. unit tests).
+
+    Note: some of these support multiple protocols (e.g. gRPC, Thrift, etc). The exact list of protocols to implement in the exporters is TBD.
+
+    Other vendor-specific exporters (exporters that implement vendor protocols) should not be included in language libraries and should be placed elsewhere (the exact approach for storing and maintaining vendor-specific exporters will be defined in the future).
 
 # Language Library Generic Design