Hi Bill, Generally if you have a Trace ID, you are also doing something that involves multiple systems, processes, or routines. If that is the case, you also need a way to cancel your resource. Thus Trace ID is included with values in the context and not separated.
When Dave voiced his own preference to separate out Value from Cancelation, the response was, "it was considered, but the benefit and complication was deemed to not be worth it". I understand what you are saying about hidden values and all, and how those aren't explicit. But I guess I don't personally care. This "not caring" can pay off where different applications have different per-request parameter needs, but want to leverage the same API for framework needs. That's my own 2 cents anyway. -Daniel On Tuesday, May 30, 2017 at 8:39:18 AM UTC-7, William Kennedy wrote: > > After reading this: > > https://cloudplatform.googleblog.com/2017/04/distributed-tracing-for-Go.html > > I can see how the Context is being used, through a separate API. Would it > make sense to use a separate Context value for the "Trace" Context and use > a separate Context value for the "Cancellation" Context in the application > independent package API's? > > I am just starting to think about these things from an API and readability > point of view. Just curious what others think. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
