Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple time ranges in the collaboration chart #115

Closed
pluehne opened this issue Feb 6, 2018 · 6 comments
Closed

Support multiple time ranges in the collaboration chart #115

pluehne opened this issue Feb 6, 2018 · 6 comments

Comments

@pluehne
Copy link
Contributor

pluehne commented Feb 6, 2018

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
Copy link
Collaborator

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

@filmaj
Copy link
Contributor

filmaj commented Feb 6, 2018

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
Copy link
Contributor Author

pluehne commented Feb 6, 2018

@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
Copy link
Contributor Author

pluehne commented Feb 12, 2018

@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
Copy link
Contributor

filmaj commented Feb 12, 2018

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
Copy link
Contributor Author

pluehne commented Feb 12, 2018

@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 🙂.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants