Intentionally I only changed Zipkin.hs and not Trace/Internal.hs:
a) It's part of the Zipkin specification, so I thought it naturally belongs to Zipkin.hs 😄
b) Other propagation standards (e.g. https://www.w3.org/TR/trace-context/#trace-id) use 128-bit - so I believe it's okay to always use 128-bit internally
c) Even if this is a internal module - it's public API - so to only change things in Zipkin.hs reduces the chance of a breaking change
But it has the drawback that the handling is somehow distributed and the implementation looks "patched".
Resolves https://github.com/mtth/tracing/issues/12
Intentionally I only changed Zipkin.hs and not Trace/Internal.hs: a) It's part of the Zipkin specification, so I thought it naturally belongs to Zipkin.hs 😄 b) Other propagation standards (e.g. https://www.w3.org/TR/trace-context/#trace-id) use 128-bit - so I believe it's okay to always use 128-bit internally c) Even if this is a internal module - it's public API - so to only change things in Zipkin.hs reduces the chance of a breaking change
But it has the drawback that the handling is somehow distributed and the implementation looks "patched".
As always, just let me know what you think.