Christian Weiss

> @Aaronontheweb this IScopeManager implementation is the default in other languages, such as Java - why should it exist in a contrib package for .NET when it's the default implementation...

fyi, I'm currently not adding this to the next release (targeting next week) for the following reasons: * I currently simply don't know enough about the internals of `ThreadStatic`, `ThreadLocal`,...

> @yurishkuro I think it was a bug in Java NoopTracer, which has been fixed. Yes and no. It probably was a bug that `scopeManager.active()` returned `null` after a call...

Would the existing `ISpan Log(string @event);` cover your scenario? #91 would also make it (slightly) easier to implement custom, more efficient, log types. I'll backlog this to wait for more...

> But if performance is not a high priority item for opentracing-csharp I can keep such things I notice to myself :) That's an unnecessary/destructive comment. Backlog just means that...

@ThomasSkyldahl PR #91 would bring that. However, it obviously still isn't as performant/easy to use as a separate `Log(string, object value)`. @opentracing/opentracing-c-maintainers (and anyone else): My request for more feedback...

> @ThomasSkyldahl I would argue that if the API has Log(IEnumerable entries) and Log(string key, object value) it should be enough, there is no need to wrap two arguments in...

`Log(string @event)` existed before key:value logging was introduced so one aspect of this is backwards compatibility - at least in Java. The C# api is still pretty young and with...

I need `ScopeManager.active` in C# to access the current `Scope` in scenarios where the library/framework I'd like to instrument only has `OnStart`/`OnStop` hooks without any chance to store the scope...

Is this a duplicate of https://github.com/opentracing/specification/issues/8 ?