Chris Stockton

@yurishkuro I don't understand how that is relevant to this topic, can you clarify what I should consider? I can't see a reason for the `Tracer()` method on the `Span`...

Well the code I audited is below, which as you can see always uses the global tracer: ``` func StartSpanFromContext(ctx context.Context, operationName string, opts ...StartSpanOption) (Span, context.Context) { return startSpanFromContextWithTracer(ctx,...

> I have no love for global tracer or global variables in general. I'd perfectly happy if we put "not recommended" disclaimers on everything in globaltrace.go and on StartSpanFromContext. **And...

@yurishkuro Do you have any argument in favor of the existing behavior? As it stands I see this as a bug for the reasons I enumerated above.

> (a) backwards-incompatible, Please explain an example which backwards compatible break is made in a correct Go program. The only way this could impact another application is if that program...

I think you are on the right path here, these are great high level goals. The only thing I don't entirely understand is the server refactoring you mention: > Making...

I see, I think that is fair since it will give you more freedom while you're refactoring everything. One thing to consider designing the internal server API is that anyone...

@fujita I some how missed this issues update, but I just looked at the `api` package and wanted to say fantastic work with changing the direction of the dependency graph....

@fujita I try to avoid returning channels with 'watch" api's since it forces you to define a bullet point list of semantics around cancellation and draining the channels. One thing...

@fujita Glad to help, the changes look great. For the `List*` API I wasn't suggesting any changes, but I definitely prefer the callback style for the type of operations those...