Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Propagator interface #55

Merged
merged 4 commits into from
Jun 28, 2019
Merged

Conversation

mayurkale22
Copy link
Member

@mayurkale22 mayurkale22 commented Jun 22, 2019

This PR adds Propagator interface.

@mayurkale22 mayurkale22 added the Discussion Issue or PR that needs/is extended discussion. label Jun 22, 2019
@mayurkale22 mayurkale22 added this to the API complete milestone Jun 22, 2019
@mayurkale22 mayurkale22 requested review from rochdev and hekike June 22, 2019 00:08
@mayurkale22 mayurkale22 force-pushed the propagation branch 2 times, most recently from 8e8441b to 9149be2 Compare June 24, 2019 17:07
* @param format the format of the carrier.
* @param carrier the carrier of propagation fields, such as an http request.
*/
inject(spanContext: SpanContext, format: string, carrier: unknown): void;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the backwards compatibility guarantees that opentelem is trying to make? In opentracing-javascript, inject is accepts either a SpanContext or Span. I'm in favor of only allowing a span context since the opentracing code ends up doing if (context instanceof Span) { context = span.context() } anyway, but want to make sure the API difference is captured in the event we make a shim down the line.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm in favor of accepting a Span everywhere a SpanContext is accepted which makes the API easier to work with.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened an issue to discuss #58

@draffensperger
Copy link
Contributor

More of a basic question here - what's the advantage of having an inject method over something like a interface Headers {[key: string]: string and then serialize(spanContext): Headers and deserialize(headers): SpanContext methods?

That way the functionality of the propagation is really all about serializing and deserializing trace context and doesn't need to worry about how to actually inject those headers. There could then be a separate utility that takes the headers and injects them into something like an HTTP, gRPC, etc. context

* Injects the given {@link SpanContext} instance to transmit over the wire.
*
* OpenTelemetry defines a common set of format values (BinaryFormat and
* HTTPTextFormat), and each has an expected `carrier` type.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Propagation can be done on non-HTTP protocols. There should be a distinction between HTTP headers and text map, similar to OpenTracing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This interface is inspired from OpenTracing codebase and OTel specs. Let me know if I missed anything here.

import { SpanContext } from '../../trace/span_context';

/** Defines a propagation interface. */
export interface Propagation {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Propagation sounds more like a namespace. The interface should probably be called Propagator.

Also, as discussed in #48 (comment) there needs to be an additional abstraction than SpanContext if SpanContext represents the W3C SpanContext.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed to Propagator .

@mayurkale22 mayurkale22 changed the title Add Propagation interface Add Propagator interface Jun 25, 2019
Copy link
Member

@rochdev rochdev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's revisit HTTPTextFormat in a future revision since it's semantically incorrect.

@mayurkale22 mayurkale22 merged commit b359f3a into open-telemetry:master Jun 28, 2019
@mayurkale22 mayurkale22 deleted the propagation branch June 28, 2019 22:10
dyladan pushed a commit to dyladan/opentelemetry-js that referenced this pull request Sep 9, 2022
* chore: move baggage methods in propagation namespace

* chore: add upgrade guidelines
dyladan pushed a commit to dyladan/opentelemetry-js that referenced this pull request Sep 9, 2022
* chore: move baggage methods in propagation namespace

* chore: add upgrade guidelines
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Issue or PR that needs/is extended discussion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants