Rename exporter-collector

[CptSchnitz]

It would be a good idea to rename the exporter to a better and clearer name.

A name like exporter-otlp will be easier to understand for newer people, and inline with the rest of the SDKs.

Also before GA is a good time to make such a change.

[vmarchaud]

cc @open-telemetry/javascript-approvers

[wong2]

yes, it's confusing

[rauno56]

@CptSchnitz, this seems to have quite a lot of support, would you like to draft a PR for it?

[CptSchnitz]

sure!

[CptSchnitz]

@rauno56 I got some questions

1. should it be renamed to exporter-otlp or exporter-otlp-http?
2. should the other exporter collector be renamed (proto and grpc)?

[wong2]

+1 for exporter-otlp-http

It takes me a while to realize it's a http exporter instead of some base exporter others relying

[vreynolds]

If I understand it correctly, there's more nuance:

• opentelemetry-exporter-collector is OTLP/HTTP (JSON)
• opentelemetry-exporter-proto is OTLP/HTTP (binary)
• opentelemetry-exporter-grpc is OTLP/gRPC

exporter-otlp-http-json? 😅

[rauno56]

If I understand it correctly, there's more nuance:

Had to look it up, but that's my understanding as well.

I'm sure there will be different preferences for that, and "the absolute most correctest" way would probably be to mention both the transport and the format as @vreynolds put it.

I'd personally leave some of that information implied.

• exporter-otlp-json - implied http
• exporter-otlp-http - implied proto
• exporter-otlp-grpc

... but that's just me! :)

[CptSchnitz]

hi didn't had the time to work on it yet and just started.
I got another question:
should the rename also include all the internal code mentions of the collector in the packages, or just the exported classes and interfaces? it makes the PR much bigger, and it can be done in a later stage, or separately for each package.

[vmarchaud]

should the rename also include all the internal code mentions of the collector in the packages, or just the exported classes and interfaces

Only the exported classes make more sense, we could improve it later on

[obecny]

my 3 cents:

• exporter-otlp-json
• exporter-otlp-proto
• exporter-otlp-grpc

[CptSchnitz]

my 3 cents:

• exporter-otlp-json
• exporter-otlp-proto
• exporter-otlp-grpc

i agree, the only thing that will be slightly "weird" is that both proto and grpc will depend on the json because it has the base class.

[vmarchaud]

i agree, the only thing that will be slightly "weird" is that both proto and grpc will depend on the json because it has the base class.

Thats just implementation details, we could in the future make a dedicated util pkg that host base classes and remove the direct dependency so i think thats fine to do it like this

[dyladan]

#2476