OpenTracing Registry Page

[austinlparker]

This is the tracking issue for the OpenTracing Registry, a page that's intended to be a searchable index of tracers, addons, plugins, and client libraries that support OpenTracing.

The intention of this registry is to improve the discoverability of OpenTracing components both inside and outside the opentracing and opentracing-contrib organizations on GitHub.

[yurishkuro]

What's the plan? A yaml or json file listing all modules and a JS fuzzy search in the UI?

[austinlparker]

Yeah, pretty much. I've already got some initial work here https://github.com/opentracing/opentracing.io/compare/feature/searchableRegistry if you want to see.

The biggest difference is that instead of a single file listing modules, we'll have a bunch of markdown files that get turned into JSON and then searched. Should make it easy for people to do PR's of new modules.

[austinlparker]

@tedsuo @yurishkuro I'm trying to come up with a set of standard registryTypes for things that can go into the registry; so far I've got 'tracer' and 'instrumentation'. I'm not really sold on either of those names or what they refer to right now, however. Y'all have any thoughts? This is a WIP screenshot of how those will be displayed. Note that I don't have a color for the 'instrumentation' badge yet, which is why it's white.

[yurishkuro]

tracer / instrumentation labels make sense to me.

I would suggest (without thinking through implementation implications) keeping the individual files in two different directories, tracers & instrumentations, so that people won't need to remember to tag them accordingly.

Another useful tag is language: Java, Go, etc.

[tedsuo]

I'm not sure if we want to have explicit categories (language, type, etc) and then some additional generic tags, or just tags.

In other words: is metadata key:value like categories, or just value like labels?

[austinlparker]

Here's a WIP gif of where I'm at with the search - I'm thinking having a single list page that has all of the items on it that you can filter/search down feels pretty good, but I'm pretty open to suggestions still.

One thing I don't really care for so far is that I'm doing a POST each time you search, so you get that annoying redraw since we're reloading the page. That said, the nice thing about doing a POST is that you can share a link with a search query (i.e., https://opentracing.io/registry/?s=Java)

[austinlparker]

@tedsuo right now metadata tags are a value array, and the type of thing is a special k:v (registryType in the below snippet, because type is reserved in Hugo front matter)

title: OpenTracing JDBI Instrumentation
registryType: instrumentation
tags:
  - java
  - opentracing
  - jdbi
  - database
repo: https://github.com/opentracing-contrib/java-jdbi
license: Apache 2.0
description: OpenTracing instrumentation for JDBI
authors: OpenTracing Contributors
---

[tedsuo]

yeah, in general this is great.. I might suggest that registryType just be a tag, so that everything is a tag. That give us flexibility (some projects may span multiple languages, so projects may be both an instrumentation lib and a tracer).

[austinlparker]

I think we're about ready for a PR to get this in so we can get more stuff added... I wrote a little program to pull all the contrib repos so we can have a bunch of stuff pre-populated.

list/search view:

single item view:

re @tedsuo suggestion of having registryType be a tag; It's a solid idea, but it proved to be very difficult to implement with the way the templating of search results works. I can discuss in more detail in chat if you'd like or on the docs site call tomorrow.

One other difference here from earlier iterations is that I added an otVersion property. I pre-populated it with latest on all the contrib projects because there's no easy way to get that info strictly from GitHub metadata. It's probably worthwhile to note that, conventionally, I'm not sure what the actual value of this field should be. My gut feeling is "the version of the language API", but maybe it should be the spec? But then what do you do about things that are written to support RFCs that aren't in the versioned spec yet? Tricky question.