In Erlang, we have a similar concept to the Context bag called the Process Dictionary. Its use is generally a nono because it breaks the rules for functional programming and allows you to have a shared space. We like to pass every argument explicitly in order to make it easier to read the code.
Yet, we've found again and again that there are situations where the value of the process dictionary outweighs functional programming. Among those are RNG state and process metadata, of which TraceIDs would be a prime example. Processes crashing list their PD as well. A rule of thumb we often use is that the things you stuff in the PD must not be something which directly affects your programs behavior, though the RNG is a borderline case. I'd also be somewhat worried if the omission of a TraceID would ever affect a system. It ought to handle a nil return when calling span.FromContext() gracefully I think. It would be akin to most of the system I write: when a message does distributive transfer, you encode and marshal its meta-data on where relevant. The structure of the meta-data is given by convention, not by explicit notion. In short: you have to balance convenience against correctness. I think Jaana's proposal manages to do just that, in particular by acknowledging this is likely to need future extension. On Wed, May 31, 2017 at 7:23 PM William Kennedy <b...@thekennedyclan.net> wrote: > I have come to the same conclusion. I just needed to write it down and > listen to a few people talk about it. Thanks for the response. > > I just want to be careful what we consider to be ok to be placed in the > Context and what truly needs to be passed in as a separate argument. > > On May 31, 2017, at 5:29 PM, Daniel Theophanes <kardia...@gmail.com> > wrote: > > 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/uaOtsp71MfM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > -- > 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. > -- 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.
