Tracer must expose getter for sampler

[SergeyKanzhelev]

Sampler access is needed if you are using recordSpanData and still want to apply sampling

[jmacd]

I can't be certain from this description, but as issue 71 lays out, I suspect would not be needed if we removed recordSpanData from the user-facing API. Could you clarify?

[SergeyKanzhelev]

@jmacd if API will be removed - there may not be a need for sampler. Right now the API is a bad place where scenario of reporting out-of-band spans using the same sampling algo is not possible.

[jmacd]

I can't understand this claim, because I still haven't see a formal argument why two APIs are required to support out-of-band reporting.

[SergeyKanzhelev]

@jmacd we discussed it a few times already. Initial agreement is formulated in Java API. And I'm saying it is not complete. Either sampler needs to be exposed or API needs to be changed. Thus the issue

[bogdandrutu]

I think this depends on the issue (which unfortunately I cannot find anymore) about keeping SpanData vs offering APIs to allow start/end timestamps.

[jmacd]

I've been digging into the SpanData API for a while now, and have teased apart several requirements it seems. They are:

(1) support recording spans with alternate resources ("out of band")
(2) support recording spans with alternate timestamps ("asynchronous")
(3) support recording lazy spans

I was confused at why the topic of the Sampler had entered the discussion about SpanData, but now I think I see it. Is there a requirement here that lazy-span reporting interact directly with the Sampler?

I.e., are we requiring (in the current spec) that a call to recordSpanData, with complete details including start and end timestamps plus accumulated span attributes, that the Sampler SHOULD use those details?

See also issue 164. I can't quite figure out why the Sampler is considered a user-facing API, vs. part of the SDK.

[SergeyKanzhelev]

SpanData API was removed. Closing the issue