Revisit naming of API and SDK packages about opentelemetry-dotnet HOT 4 CLOSED

I believe keeping Abstractions is pretty consistent with .NET practices (Microsoft ships a lot of packages named like Microsoft.Extensions.Logging.Abstractions or Microsoft.AspNetCorte.Http.Abstractions) and we should keep it here.
I recall OpenCensus had the statement somewhere that typical language practices should be used - can't find it now, do we still prefer it over having the same API everywhere in OpenTelemetry?

from opentelemetry-dotnet.

Idiomatic language practices are good, but what worries me is that we'll end up polluting OpenTelemetry.Abstractions with interfaces that are specific to the reference implementation.

from opentelemetry-dotnet.

For me it was a bit confusing at first, not finding the "Api" and "Sdk" layers anywhere. Also "Api" and "Sdk" terms come up in conversations sometimes and it's a bit weird to not have them reflected in the project names.

However, no strong opinion on this. It's good to be idiomatic to a tech.

Concerning "Abstractions": Which interfaces is it supposed to hold exactly?

1. For implementers of "Instrumentations"
2. For implementers of "Tracers"
3. For implementers of "Exporters"

Currently, all the above I would guess. Would it make sense to split out 1. into an "Api" project with minimal API surface?

from opentelemetry-dotnet.

I have the same reservations about Abstractions. SDK will have bigger public surface area than API. API package will mostly be for the libraries instrumentation like OpenTracing before

from opentelemetry-dotnet.