search

open-telemetry / opentelemetry-specification

Specifications for OpenTelemetry
https://opentelemetry.io
Apache License 2.0
3.64k stars 871 forks source link

Define conventions for Registry types. #595

Open austinlparker opened 4 years ago

austinlparker commented 4 years ago

I'm working on Registry enhancements (see https://github.com/open-telemetry/opentelemetry.io/issues/103#issuecomment-626934733 for a WIP image) that requires a quick consensus on a few names. We'll have the ability in the registry to filter by both language and 'type'. Here's my proposed types -

Open questions:

  1. Should API and SDK be combined? They're separate because some SIGs have a separate API and SDK implementation, but I'm not entirely convinced that's the best option. A potential change here would be to combine API and SDK into 'Implementations' and allow for multiple URLs for this type (so you could link to API and SDK independently if they are in independent repositories)
  2. Are we happy with 'Instrumentation' to be a catch-all for instrumentation plugins? Is this terminology confusing to new users? We can also just display it as 'Instrumentation Plugin' and keep the underlying type key 'instrumentation'
  3. Should 'Collector' be a type or a language (or both?) The current taxonomy makes collector exporters kinda weird, as they're exporters (so they should be tagged exporter) but they're for the collector (so they should be tagged collector).
  4. Is there anything missing?

Thanks in advance for feedback.

austinlparker commented 4 years ago

After noodling on this a bit, I'm thinking about combining API and SDK into 'Core', so we'd have 'Core', 'Collector', 'Exporter', and 'Instrumentation'.