| 1 | ;
|
| 2 | Object.defineProperty(exports, "__esModule", { value: true });
|
| 3 | /**
|
| 4 | * The FORMAT_BINARY format represents SpanContexts in an opaque binary
|
| 5 | * carrier.
|
| 6 | *
|
| 7 | * Tracer.inject() will set the buffer field to an Array-like (Array,
|
| 8 | * ArrayBuffer, or TypedBuffer) object containing the injected binary data.
|
| 9 | * Any valid Object can be used as long as the buffer field of the object
|
| 10 | * can be set.
|
| 11 | *
|
| 12 | * Tracer.extract() will look for `carrier.buffer`, and that field is
|
| 13 | * expected to be an Array-like object (Array, ArrayBuffer, or
|
| 14 | * TypedBuffer).
|
| 15 | */
|
| 16 | exports.FORMAT_BINARY = 'binary';
|
| 17 | /**
|
| 18 | * The FORMAT_TEXT_MAP format represents SpanContexts using a
|
| 19 | * string->string map (backed by a Javascript Object) as a carrier.
|
| 20 | *
|
| 21 | * NOTE: Unlike FORMAT_HTTP_HEADERS, FORMAT_TEXT_MAP places no restrictions
|
| 22 | * on the characters used in either the keys or the values of the map
|
| 23 | * entries.
|
| 24 | *
|
| 25 | * The FORMAT_TEXT_MAP carrier map may contain unrelated data (e.g.,
|
| 26 | * arbitrary gRPC metadata); as such, the Tracer implementation should use
|
| 27 | * a prefix or other convention to distinguish Tracer-specific key:value
|
| 28 | * pairs.
|
| 29 | */
|
| 30 | exports.FORMAT_TEXT_MAP = 'text_map';
|
| 31 | /**
|
| 32 | * The FORMAT_HTTP_HEADERS format represents SpanContexts using a
|
| 33 | * character-restricted string->string map (backed by a Javascript Object)
|
| 34 | * as a carrier.
|
| 35 | *
|
| 36 | * Keys and values in the FORMAT_HTTP_HEADERS carrier must be suitable for
|
| 37 | * use as HTTP headers (without modification or further escaping). That is,
|
| 38 | * the keys have a greatly restricted character set, casing for the keys
|
| 39 | * may not be preserved by various intermediaries, and the values should be
|
| 40 | * URL-escaped.
|
| 41 | *
|
| 42 | * The FORMAT_HTTP_HEADERS carrier map may contain unrelated data (e.g.,
|
| 43 | * arbitrary HTTP headers); as such, the Tracer implementation should use a
|
| 44 | * prefix or other convention to distinguish Tracer-specific key:value
|
| 45 | * pairs.
|
| 46 | */
|
| 47 | exports.FORMAT_HTTP_HEADERS = 'http_headers';
|
| 48 | /**
|
| 49 | * A Span may be the "child of" a parent Span. In a “child of” reference,
|
| 50 | * the parent Span depends on the child Span in some capacity.
|
| 51 | *
|
| 52 | * See more about reference types at https://github.com/opentracing/specification
|
| 53 | */
|
| 54 | exports.REFERENCE_CHILD_OF = 'child_of';
|
| 55 | /**
|
| 56 | * Some parent Spans do not depend in any way on the result of their child
|
| 57 | * Spans. In these cases, we say merely that the child Span “follows from”
|
| 58 | * the parent Span in a causal sense.
|
| 59 | *
|
| 60 | * See more about reference types at https://github.com/opentracing/specification
|
| 61 | */
|
| 62 | exports.REFERENCE_FOLLOWS_FROM = 'follows_from';
|
| 63 | //# sourceMappingURL=constants.js.map |
| \ | No newline at end of file |