These are chat archives for HdrHistogram/HdrHistogram
regarding JS I was wondering what the use case would be (server side JS or browser side). Since you mention browser side it means you really only need the consumption side of HdrHistogram (that is decode and display).
Visualizing histograms is great and always needed. But just decoding a histogram is not always sufficient because it lacks the associated semantic.
If you look at wrk2 which is a good model for all the distribution/aggregation of collected values, the encoded histogram ned to be sent to a collector along with some app specific content. Today we have been using a proprietary protocol, which is to encapsulate the encoded histogram into a json container that holds application specific fields - things that go with the histogram content - e.g. sender ID, rate in request/second, number of connections, error counts, duration of capture... and we send that to the collector using Redis.
If we could define a standard protocol for doing the same thing with the corresponding libraries (in C, java, python...), then people would not have to reinvent this every time in their own way. Just thinking out loud: websocket + a well known websocket protocol to be registered at IANA (http://www.iana.org/assignments/websocket/websocket.xhtml) + a flexible encapsulation that allows apps to put in their own fields (easy with json).
That would have saved me a lot of time and that clearly helps a lot in adoption