One shortcoming: these requests are always HTTP GETs, and various web browsers/servers/proxies will impose different limits on the length of the request. In t

One shortcoming: these requests are always HTTP GETs, and various web browsers/servers/proxies will impose different limits on the length of the request. In the best case, it looks like you're going to get 8k requests, and if you're dividing that up among multiple timeseries, it's not a _whole_ lot of data points. You'll also end up needing to do a length check client side, since the degradation is probably not graceful as you approach the request limit (fine, fine, fine, fine, fine, HTTP 414). That's probably fine for a lot of use cases, but if you adopt this charting library / system and then later want to do more complicated things with it, you're going to end up needing to rip it out and replace it with something else that doesn't have this limitation. I don't see a way around it, you can't make the browser POST to get the img tags AFAIK.