Hi Raam, As you know, OpenTracing is an API which uses other tracing systems as the backend. So, for example, you can use OpenTracing with a proprietary backend. Or you can use OpenTracing with Zipkin as the backend. In this context, the function of the "backend" is to store and process the spans.
There was some recent discussion on the mailing list about setting up an OpenTracing connector that would send spans to HTrace. That sounds like a good initiative, and perhaps that's what you mean by "OpenTracing compliant"? As I remember, the main difference between HTrace and OpenTracing data models was about whether spans should have multiple parents or a single parent. The single-parent model was simpler to display in GUIs, but it leads to people needing to use other IDs to associate related groups of spans. This is something we might revisit in the future if there are better ways of doing the same thing, but for now we have multiple parents. In any case, this will not prevent an OpenTracing-to-HTrace connector from being written if people want one. best, Colin On Mon, Mar 20, 2017, at 09:49, Raam Rosh-Hai wrote: > Hi Guys, > > For my talk about tracing scala application I talk about Htrace and > zipkin, > After reading the opentracing spec it seems like htrace does follow most > if not all of the open tracing spec, for completeness and correctness I > would really appreciate it if someone can describe what is missing in > order > for Htrace to opentracing implementation. > > I am not implying it's neceserry that htrace should be complaint but I > think it would be interesting to highlights the differences if any > between > the methods. > > Thanks, > Raam
