open-telemetry
Provide a module for SDK interfaces implemented externally
Is your feature request related to a problem? Please describe. Currently, any SPI between the SDK and exporters is within the SDK modules.
Having the SPI within the SDK implementation has several impacts:
- There's no API boundary between the SDK and exporters. Exporters can potentially utilize parts of the SDK that weren't intended
- It complicates implementing exporters for those not familiar with the project, as it requires knowing which interfaces/classes from the SDK need to be implemented
- A separate module would make it possible to independently version, resulting in longer compatibility between SDK and exporters if the SPI has not been modified
Describe the solution you'd like Either a pure SPI module that only contains interfaces or more of a "common" SPI module that includes the interfaces but also common classes that are required by both the SDK and exporters. Whichever approach can be taken will be influenced by the current SDK implementation and how easily some of those "common" SPI pieces can be extracted.
I'm happy to prototype this work if there's interest
@kenfinnigan since we've moved all the SPI into the autoconfigure module, does that satisfy your needs?
I don't believe it does, as something like https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/trace/src/main/java/io/opentelemetry/sdk/trace/export/SpanExporter.java I would consider an exporter SPI which is present in the SDK.
Anything implementing an exporter needs to depend on the entire SDK to access that interface to implement it, leading to the possible problems I described above.
Is there any particular need or requirement for exporters to depend on the full SDK?
oh yeah... I forgot about that specific bit. Basically you'd like a stable set of interfaces (not SPI in particular) for what @tedsuo has been calling "SDK Plugin Interfaces". Maybe we can update the description of this issue so I don't get confused by the "SPI" bit in the title in 2 months when I scrub though the issues again. :)
I took SPI as just meaning interfaces between the SDK and external bits, maybe there's a specific meaning I'm not aware of which is where the confusion came from.
I've updated the title to hopefully something more meaningful. If not, feel free to adjust
@kenfinnigan Sorry for missing this issue last year. Unfortunately, I don't know if this is possible anymore until a V2 of the SDK - we don't want to move the package names for these interfaces, and if I'm not mistaken, if we tried to extract without renaming packages, we'd run into JPMS / OSGI issues (not saying we don't already have issues, but we want to get better of course :P). Do you know of an approach we could take to solve this issue now or should we leave it open for a long term feature request, or if you're ok with it close it as unfeasible?
For context, there are many classes related to our plugin interface, including
SpanExporter
SpanData (and several other *Data)
Resource
Sampler
SamplingDecision
CompletableResultCode
I unfortunately just don't see us being able to extract these out at this point but it could be a potential design decision for SDK v2. SDK v2 is something I don't want to think about for a long time though :-)
There's no API boundary between the SDK and exporters. Exporters can potentially utilize parts of the SDK that weren't intended
Exporters don't need to depend on the SDK but exporters also can't function at all if the user doesn't have the SDK. So while I do understand the aspect that for authors of custom exporters, or any implementation of our "SDK plugin interfaces", it might be confusing to have the whole SDK on the compile classpath, I think for end users there isn't really a big difference since they need both on the runtime classpath anyways. So this seems OK to me as we expect exporter writers to be more familiar with OpenTelemetry anyways, even if it's not ideal.
It complicates implementing exporters for those not familiar with the project, as it requires knowing which interfaces/classes from the SDK need to be implemented
I think we can help with this with docs even if we can't extract a module.
