SpanId/TraceId generation

[carlosalberto]

While testing out the testbed for the OT Shim (and its related in-memory Tracer), I realized that random generation of SpanId and TraceId is gone (it's part of the main API in OC).

Any reason to truly remove it, other than reducing the exposed API? That being said, I'd like to at least have access to something like SpanId.create(long).

[bogdandrutu]

The random generation of the Trace/Span id will be in the SDK. Main reason is that for example to support Amazon X-Ray the TraceID needs to be a specific format for example, also that is an implementation detail.

[carlosalberto]

I'm wondering if it would be helpful to expose the constructors, nevertheless - otherwise, user will most likely have to use UUID + string manipulation to pass a byte [] to SpanId/TraceId to create new ids ;)

[carlosalberto]

Hey @bogdandrutu any opinion on this last comment? If you really think we don't need this, lets close this Issue (and perhaps discuss it in the future if/as needed)

[tedsuo]

If TraceID() and SanID() generators are on the Tracer interface, we can defer the the implementation's choice of ID schemes.

[tedsuo]

For now, we are going to keep these methods private/protected, as we know we need to support customer TraceID's in the future (AWS xray, etc).