* [ ]  Add a file backend for replay (there is a [file exporter](https://pkg.go.dev/github.com/open-telemetry/opentelemetry-collector-contrib/exporter/fileexporter#FileExporter) in development - it might work).

When I looked at this, it looked tricky to do, as you'll need to collect traces from sub-processes as well. I didn't see the package you're linking though, so maybe it's possible. The best I had come up with is to maybe run a collector in the main CLI and have all plugins connect back to that to send traces.

  * I think this is necessary so users can submit their traces to us.

Jaeger does have a "export to JSON" option, which might be workable. It's obviously not as nice as just writing to a file directly, but might be okay if it makes things easier.

* [ ]  Convert existing open tracing to OTEL

We might want to support both for a while, since users might be using older providers which only support opentracing. It's also a breaking change to remove--tracing. Even though it's unlikely that anyone is using it in an automated way, we should still be careful about it.

* [ ]  Add a file backend for replay (there is a [file exporter](https://pkg.go.dev/github.com/open-telemetry/opentelemetry-collector-contrib/exporter/fileexporter#FileExporter) in development - it might work).

When I looked at this, it looked tricky to do, as you'll need to collect traces from sub-processes as well. I didn't see the package you're linking though, so maybe it's possible. The best I had come up with is to maybe run a collector in the main CLI and have all plugins connect back to that to send traces.

We might still need to do that. I think this package is more about a stable file format. We will still need to figure out how to pass a server address down to language hosts (and ultimately providers).

  * I think this is necessary so users can submit their traces to us.

Jaeger does have a "export to JSON" option, which might be workable. It's obviously not as nice as just writing to a file directly, but might be okay if it makes things easier.

I saw that. I'm really hoping it won't be necessary, but let's see. 😄

* [ ]  Convert existing open tracing to OTEL

We might want to support both for a while, since users might be using older providers which only support opentracing. It's also a breaking change to remove--tracing. Even though it's unlikely that anyone is using it in an automated way, we should still be careful about it.

I'm of 2 minds here. Removing the--tracing flag would be breaking, but if we convert our existing spans to OTEL then--tracing will start emitting empty traces. Maintaining full backwards compatibility by back-porting OTEL traces to opentracing seems like more effort then its worth.

We could start by adding an--otel flag and deprecating--tracing (as in your PR).

We could start by adding an--otel flag and deprecating--tracing (as in your PR).

Yeah I think that's the way to go. Imo we should just keep--tracing as it is, still emitting opentracing traces, essentially not changing anyting yet other than deprecating it, and add a--otel flag that is just additive.

We could start by adding an--otel flag and deprecating--tracing (as in your PR).

Yeah I think that's the way to go. Imo we should just keep--tracing as it is, still emitting opentracing traces, essentially not changing anyting yet other than deprecating it, and add a--otel flag that is just additive.

The issue there is how traces are emitted from our CLI code. If I want to add a new span to a function and I use OTEL to do so, then it won't show up in the opentracing output. Keeping--tracing long term means that we can never switch our tracing code to emit OTEL spans / metrics / logs. AFAIK we can bridged opentracing into OTEL, but not vice versa.

If I want to add a new span to a function and I use OTEL to do so, then it won't show up in the opentracing output.

Sure that's fine, we don't need anynew stuff to show up inopentracing, just preserve what we have until now. I also don't think we should support--tracing long term, but it should work through a deprecation period long enough to give everyone (including providers) to move over to otel.