[docs] Document feature matrix for client libraries

[yurishkuro]

First column:

• standard tracer metrics
• standard rpc metrics
• logging reporter
• configurable
• env configurable - Java only atm
• remotely controlled sampler
• adaptive sampling
• baggage restrictions
• reporter: Jaeger Thrift over UDP
• reporter: Zipkin Thrift over UDP (Python client still does that, needs upgrade)
• reporter: Jaeger Thrift over HTTP
• reporter: Zipkin Thrift over HTTP
• reporter: Jaeger JSON over HTTP - don't think we have any, just i case. Node.js might be a good candidate for that
• reporter: Zipkin JSON over HTTP - don't think we have any, just i case
• Uber headers format
• Zipkin/B3 headers format
• in the future - other formats

The other columns are for individual clients

• header - language and link to the repo
• values - ✅ :white_check_mark: or ❌ :x: + optional link to open issue
  • :white_check_mark: is a bit long, could use 🆗 :ok:

[pgadige]

I'd like to build this feature matrix. I'd consider Jaeger client libraries in GO, Java, Python, Node and C++ on successive columns, and determine whether each feature in the first column is present/supported or not in each of the above client libraries? Could you please provide a hint on where to gather information about each feature, for instance, code snippets, other documentation posts?

[yurishkuro]

Hi @pgadige ,

Thanks for offering to help with this. The only reliable way to determine if a feature is supported is to actually check the code (sometimes README) of each of the clients. We can actually start with setting up the document structure and just filling cells with a question mark, at least for things that you're not sure about.

Another thing I was thinking of is what format should the source of this information take. We can certainly create a table in Markdown, but my concern is that it will be very hard to maintain due to formatting issues, e.g. say we want to add a link to an existing issue for one of the cells, it would change the cell width significantly, making the table very hard to edit. A more maintainable way would be if we used some config file format, e.g. yaml, to define the features for each client, and then generate the Markdown from that yaml file programmatically. For example:

java:
    standard_tracer_metrics: yes
    standard_rpc_metrics:    no
go:
    standard_tracer_metrics: yes
    standard_rpc_metrics:    yes
python:
    standard_tracer_metrics: custom
    standard_rpc_metrics:    no - https://github.com/jaegertracing/jaeger/issues/384

etc. We can use a simple python script to read this file and produce a Markdown table