Extract OpenTracing dependencies from dd-sdk-ios and use as a dependency

[joshskeen]

The thing

Including the opentracing dependencies as a copy inside of the dd-sdk-ios library breaks decoupling of components that will share tracing capabilities with other modules.

Tell us the thing 🙂

Instead, those modules that require just opentracing behavior now require us to import the entirety of the datadog sdk to use the tracing interfaces.

The android datadog sdk on the other hand decouples these dependencies, making it much easier to provide an opentracing interface to consumers of trace behavior.

iOS should bring their sdk in line with this design.

[ncreated]

@joshskeen The OT (OpenTracing) interface implemented by Datadog iOS Tracer is indeed a copy of opentracing-swift interface. We made efforts to use it as an external dependency (see opentracing/opentracing-swift#11), so our users could instrument their code against OT and avoid vendor locking. Due to no response, we decided to provide "conventional conformance" instead and copy the OT APIs to our project.

Speaking of today, where OT is officially deprecated and OpenTelemetry (OTel) is considered the new standard, we work on changing our iOS Tracer to be OTel-compatible. This may include extracting tracer interface or consuming it from official dependency (see opentelemetry-swift). If you are in favour of externalizing opentelemetry-swift interfaces, you can check the proposal we opened in open-telemetry/opentelemetry-swift#486.

Let us know if this makes sense to you 🙂.

[ncreated]

@joshskeen 👋 We finally achieved the API split in 2.14.0 🎉. Like I said earlier, we implement Open Telemetry API, not Open Tracing as the latter is a deprecated standard. With 2.14.0 it is possible to instrument the code using OTel API and use Datadog iOS Tracer as implementation detail to avoid vendor-locking.

Because 2.14.0 achieves the split in subject and because no further work is planned for Open Tracing conformance on our side I'm closing this issue.