Confusing transport protocols

[iNikem]

The spec currently says:

OTLP has more than one transport protocol it can support, e.g. grpc, http/json, http/protobuf

That is all that is said about this. Is this list exhaustive? MUST every SDK support them all? What exactly do they mean? E.g. what is the difference between gRPC and http/protobuf when gRPC already sends protobuf encoded data over HTTP.

[seemk]

This is indeed somewhat confusing, I'd love if an SDK would be compliant to the spec if at least one of OTLP transports is satisfied, but not all of them.

I think forcing the implementation of OTLP over gRPC/http2 would be too cumbersome for new SDKs and omitting it would simplify building/packaging, as http2 is not a trivial spec and this complexity is not needed for trivial data transfer.

[tigrannajaryan]

what is the difference between gRPC and http/protobuf when gRPC already sends protobuf encoded data over HTTP.

OTLP grpc requires HTTP 2 and is a transport that is built on top of it. OTLP http/protobuf works over a regular http transport (including http 1.1).

I'd love if an SDK would be compliant to the spec if at least one of OTLP transports is satisfied, but not all of them.

I am in favour of requiring only one transport to be implemented by the SDK and letting SDKs to decide if they want to implement more than one.

However, I wonder if we should make a choice in the spec of which OTLP transport is mandatory and which are optional. This would avoid each SDK having a different default OTLP transport.

Can we go with OTLP/HTTP/Protobuf as the required one (and the default) and the rest of the OTLP transports and encodings are optional?

[bogdandrutu]

Based on the discussion in the Specs meeting, we believe that would be good to ask SDKs to support both grpc and http since the translation from internal SpanData to protos can be shared, the code to call the client is minimal.

[obecny]

in js the exporter collector supports:

1. node.js: grpc, protobuf over http and json over http.
2. browser: json and we use XMLHTTPRequest or sendBeacon if no headers are set.

So as you can see the user can decide what transport he will need. Based on transport we have 3 different version of exporter collector, the base is using json as this is built in either in node.js or browser.
grpc and proto requires additional packages so they extend the base with missing packages. This way the user has freedom to choose and is not limited to anything. Also such separation allows to load minimum packages that are needed for user needs which is especially important in browser where you would not want to load anything what is not needed.

[carlosalberto]

@obecny Thanks a lot for the feedback. So as the JS SIG implements the three OTLP flavors already, I'd suggest going ahead with @bogdandrutu's suggestion above and ask the rest of the SIGs to support grpc and http/protobuf.

[seemk]

When looking at the current compliance matrix it shows that at least one of OTLP/gRPC, OTLP/HTTP binary protobuf, OTLP/HTTP json protobuf has to be implemented, but not all of them.

The change was done in: #1359 so quite a while ago.

Can we leave it as is?

My personal opinion is that gRPC should not be made mandatory anywhere for OTLP. I'm fine with the current state.

[shakuzen]

My personal opinion is that gRPC should not be made mandatory anywhere for OTLP. I'm fine with the current state.

Doesn't the current state allow for only supporting gRPC (meets the at least one of requirement), which would effectively make it mandatory in that SDK? I agree with your statement that gRPC should not be mandatory anywhere, but it seems the current state allows that to happen.

[seemk]

My personal opinion is that gRPC should not be made mandatory anywhere for OTLP. I'm fine with the current state.

Doesn't the current state allow for only supporting gRPC (meets the at least one of requirement), which would effectively make it mandatory in that SDK? I agree with your statement that gRPC should not be mandatory anywhere, but it seems the current state allows that to happen.

Yeah, although as I understand, it would be the decision of SDK authors to support it or not, and compliance can be achieved by just having OTLP/HTTP binary protobuf.