Ensure compatibility with other libraries

[rochdev]

In order for distributed tracing to work properly across languages/libraries, the format of messages in the different carrier formats should be consistent.

I have drafted a specification for my JavaScript implementation, and I would like to collaborate with you to make it evolve into a final version. I based the current specification on your project since it seemed to be the only OpenTracing implementation for Datadog (until now :). I haven't included the parent ID since I didn't understand its purpose (the span ID is the actual parent ID of the next span, so the parent ID would be the ancestor).

Please let me know what you think!

[rochdev]

I am thinking on moving to ot-tracer- and ot-baggage- as text map prefixes. It seems to be what every example and most implementations are doing right now, so there are more chances for interoperability since new implementations are more likely to follow the common pattern.

@gchaincl What do you think? I would like to finalize this spec ASAP so I can finish version 1 of the JavaScript implementation and then help with yours :)

[qustavo]

@rochdev the draft looks like a great initiative, I'd be happy to collaborate to achieve consistency. You're right, propagate the ParentID doesn't make too much sense and it should be removed.

Regarding moving to ot- prefix, it makes sense if that's the standard, but AFAIK zipkinbg for example uses B3 (BigBrotherBird), so I think each implementation uses a different prefix, but I'm not completely sure.

[rochdev]

My observation was based on these libraries:

https://github.com/opentracing/basictracer-go/blob/master/propagation_ot.go https://github.com/opentracing/basictracer-python/blob/master/basictracer/text_propagator.py https://github.com/opentracing/basictracer-javascript/blob/master/src/propagation.js https://github.com/lightstep/lightstep-tracer-javascript/blob/master/src/imp/tracer_imp.js

However, I agree that this is in no way a standard. I was just thinking that if someone would build for example a python custom tracer, there are more chances of them using the ot- prefix if they look at the examples (I know I did when I started my tracer before I found your library).

I'm fine with leaving it as is if you think it's unnecessary since like you said it's inconsistent anyway.