Support multiple time ranges in the collaboration chart

[pluehne]

It would be nice to have a view switcher for the collaboration chart that supports multiple time ranges.

In this way, we could render the collaboration chart with data from:

• the last two months
• the last two years
• all data (@larsxschneider: Would this make sense?)

For this to work, we’ll need support for multiple data URLs (one for each view), because one file can’t trivially hold the data for all time ranges.

[larsxschneider]

I think all data isn't too useful in that context as the collaboration chart has no time axis.

[filmaj]

Does it make sense to 'split' the data by time chunks up using different URLs / tsv files? What about doing the slicing on the client side?

[pluehne]

@filmaj: That would be desirable, I agree. But the collaboration chart data is a matrix and not a simple key/value TSV file like the others. As putting multiple such matrices in the same TSV file would get confusing and difficult to parse, we thought it best to have multiple data files in this particular case.

With that said, we want to keep the data slicing on the client side for the other charts and resort to multiple data files only when necessary.

[pluehne]

@filmaj: @larsxschneider and I reconsidered this. We now think that multiple URLs have drawbacks of their own (for instance, multiple HTTP requests per chart and cluttering hubble-data storage).

Also, I came to the conclusion that storing multiple matrices inside the same data file might not be problematic. As @larsxschneider pointed out, they aren’t human-readable (or at least usable in a spreadsheet editor), as opposed to the history and list charts. Additionally, the header of each matrix contains as many columns as there are rows following. In this way, our parser will know exactly how many lines of text to expect and where each of the matrices begins and stops.

So, I’m working on the client-side slicing implementation now 🙂. Thanks for the feedback, @filmaj!

[filmaj]

Cool! Yeah some larger monitoring / visualization systems, like Grafana or Kibana, when dealing with massive amounts of data, use the 'query relevant slice of data from the server' approach. Smaller visualization systems (like the Chart.js library we use) assume we have all of the data up front and slice up on the client side. So I guess following this trend, the decision should basically come down to how much data do we expect Hubble to handle at a time. I have a feeling this requirement could change over time, but that's a worry for Future Us.

[pluehne]

@filmaj: For the medium-term future, I think that it is reasonable safe to assume that there are only few, small, quick-to-process data files per HTML page. The collaboration chart might be an exception, but I think it should still be manageable by browsers with three views. Also, I think that we won’t have a much more complex chart in the foreseeable future 🙂.