Add metrics exporter requirements to the metrics SDK spec

specification/metrics/sdk.md

@@ -303,6 +303,80 @@ Push Metric Exporter sends the data on its own schedule. Here are some examples:
 * Sends the data based on a user configured schedule, e.g. every 1 minute.
 * Sends the data when there is a severe error.
 
+#### Interface Definition
+
+Push Metric Exporter MUST support the following functions:
+
+##### Export(batch)
+
+Exports a batch of `Metrics`. Protocol exporters that will implement this
+function are typically expected to serialize and transmit the data to the
+destination.
+
+`Export` will never be called concurrently for the same exporter instance.
+`Export` can be called again only after the current call returns.
+
+`Export` MUST NOT block indefinitely, there MUST be a reasonable upper limit
+after which the call must time out with an error result (Failure).
+
+Any retry logic that is required by the exporter is the responsibility of the
+exporter. The default SDK SHOULD NOT implement retry logic, as the required
+logic is likely to depend heavily on the specific protocol and backend the metrics
+are being sent to.
+
+Individual language clients can decide how to associate
+[Resource](../resource/sdk.md) with `Metrics`. Refer to the [tracing SDK
+specfication](../trace/sdk.md#additional-span-interfaces) for more information.
+
+**Parameters:**
+
+`batch` - a batch of `Metrics`. The exact data type of the batch is language
+specific, typically it is some kind of list.
+
+Returns: `ExportResult`
+
+`ExportResult` is one of:
+
+* `Success` - The batch has been successfully exported. For protocol exporters
+  this typically means that the data is sent over the wire and delivered to the
+  destination server.
+* `Failure` - exporting failed. The batch must be dropped. For example, this can
+  happen when the batch contains bad data and cannot be serialized.
+
+Note: this result may be returned via an async mechanism or a callback, if that
+is idiomatic for the language implementation.
+
+##### ForceFlush()
+
+This is a hint to ensure that the export of any `Metrics` the exporter has
+received prior to the call to `ForceFlush` SHOULD be completed as soon as
+possible, preferably before returning from this method.
+
+`ForceFlush` SHOULD provide a way to let the caller know whether it succeeded,
+failed or timed out.
+
+`ForceFlush` SHOULD only be called in cases where it is absolutely necessary,
+such as when using some FaaS providers that may suspend the process after an
+invocation, but before the exporter exports the completed spans.
+
+`ForceFlush` SHOULD complete or abort within some timeout. `ForceFlush` can be
+implemented as a blocking API or an asynchronous API which notifies the caller
+via a callback or an event. OpenTelemetry client authors can decide if they want
+to make the flush timeout configurable.
+
+##### Shutdown()
+
+Shuts down the exporter. Called when SDK is shut down. This is an opportunity
+for exporter to do any cleanup required.
+
+Shutdown should be called only once for each `MetricExporter` instance. After
+the call to `Shutdown` subsequent calls to `MetricExporter` are not allowed and
+should return a Failure result.
+
+`Shutdown` should not block indefinitely (e.g. if it attempts to flush the data
+and the destination is unavailable). OpenTelemetry client authors can decide if
+they want to make the shutdown timeout configurable.
+
 ### Pull Metric Exporter
 
 Pull Metric Exporter reacts to the metrics scrapers and reports the data

specification/metrics/sdk_exporters/in-memory.md

@@ -5,3 +5,9 @@
 Note: this specification is subject to major changes. To avoid thrusting
 language client maintainers, we don't recommend OpenTelemetry clients to start
 the implementation unless explicitly communicated.
+
+The in-memory exporter accumulates telemetry data in the local memory and allows
+to inspect it (useful for e.g. unit tests).
+
+The in-memory exporter MUST support [push](../sdk.md#push-metric-exporter) mode.
+The support for [pull](../sdk.md#pull-metric-exporter) mode is TBD.