[kstenerud]

Yes, because then the library developer can define all of the things that COULD be interesting, and leave it to the user of the library to decide WHAT to record (filters), and WHERE to record it (exporters).

And since this is a standard, it means that when a user includes a bunch of disparate libraries/remote calls in his app, he can define his instrumentation wishes once for everything during app initialization. The libraries can even cooperate since they use the same underlying API and concepts for instrumentation.

[gobwas]

> Yes, because then the library developer can define all of the things that COULD be interesting, and leave it to the user of the library to decide WHAT to record (filters), and WHERE to record it (exporters).

I agree that this uppercase words can be called as somewhat purposes of the tracing API. I believe also that I was talking exactly about the same approach in the article. But I can't get how sticking to one particular library will help here? In other words, I think it will just greatly reduce the usage options.

What Im saying is that you can leave the generic hooks in the library (as it described in the article and gtrace) and then let the user choose which library to use inside what hooks.

[kstenerud]

With a standard library and API that everyone adheres to, you just pass in some initial configuration during app initialization to decide which libraries record what kinds of information. The user only touches one file to enable and choose instrumentation.

With hooks, you get nothing unless you hook, which means you have to write hooks for everything you're interested in (and also come up with a way to export the data), and so the user must touch code all over the place.